Consider DisableThreadLibraryCalls for STL dll and its satellites

[AlexGuteniev]

Magic statics are avoided for performance, to make DisableThreadLibraryCalls effective. From #673 (comment):

If the DLL uses TLS (e.g. due to magic statics), this call has no effect, leading to DllMain being called on thread start/end, which increases costs.

But STL DLLs themselves do not call DisableThreadLibraryCalls.
With added sattellites, the impact grows.

[StephanTLavavej]

This might be possible, but we're uncertain as to whether DisableThreadLibraryCalls is safe to call from DllMain (if not, it looks like we don't have a good place to call this?). Billy O'Neal (@BillyONeal) thinks it is safe, though. We're not aware of any thread-local state we maintain ourselves, but haven't looked into it.

[AlexGuteniev]

we're uncertain as to whether DisableThreadLibraryCalls is safe to call from DllMain (if not, it looks like we don't have a good place to call this?).

That's right, DllMain is the only place to call it, and the function is documented to be called from there, so it is safe.

The only problem I see is that proving benchmark is very hard to conduct.

[BillyONeal]

IMO this one falls into the 'blindingly obviously good' category so I would be happy without a benchmark.