Precompiled headers avoid duplicate work.
If you've only got a single TU using a particular PCH, then there's no duplicate work, so it can only add overhead.
We don't need to totally abandon PCHs for these targets, though, as CMake lets us reuse the PCH from components.
If you've only got a few TUs in a target, it's *probably* faster to get components' PCH for free and eat the cost of it not being perfect than it is to make a perfect PCH from scratch.
Note that I don't know if there are drawbacks due to components having a couple of private precompiled headers that wouldn't have otherwise propagated or these targets having different build flags.
I can't test it locally right now as my linker's regained the deadlocking issue it had the other day.
If it turns out there are problems, then for the single-TU targets, simply avoiding using PCHs for them at all will still be an improvement over the status quo.
For the two-or-three TU targets, we'll have to actually measure things.
Apparently we'd never bothered opting in, despite nearly everything in all out apps being entirely compatible and designed with long paths in mind.
GetModuleFileNameW is a bit awkward as it's just about the only Win32 function that returns the minimum of the buffer size and the string size - nearly everything else returns the full size even if it won't fit, so you can pass it a null pointer and a size of zero, and it'll tell you how much space you need to allocate.
I pretty much just copied the mostly-working long-path-friendly call site in the crash catcher to windowspath.cpp, but I also noticed that if the function failed and returned zero, the original implementation would loop forever, so I fixed that.
There was some code that could be ditched from the catch monitor as \\?\ is a prefix you can use to opt into long paths for a single API call instead of using the manifest to set it everywhere.
Topic info records need to have specific order defined via mNext and mPrev
fields (next and previous records). When loading multiple files a record may be
inserted into middle of the topic but neighborhood records may not be aware of
it. Having the order it's possible to move the records within one topic.
Sort the record once after loading all content files but preserve the order for
all other operations. Use std::map to group info ids by topic to make sure the
topics order is stable. Keep order within a topic for info ids on loading new
records. Use this order later for sorting the records.
