Use forwarders to avoid double indirection and have better performance

In module definitions file there's such syntax:

EXPORTS
   func2=other_module.func1

They add one-time complication for loader at DLL load time, but then they optimize away unnecessary indirect call: import address table entry of caller directly points to final implementation, rather than pointing to proxy module and having another indirect all.

Some trivial fast on fast path synchronization functions that are potentially on critical path could benefit
https://github.com/microsoft/STL/blob/852a3085906108045a3951064baaf4952f596e9e/stl/src/cthread.cpp#L97-L99

https://github.com/microsoft/STL/blob/852a3085906108045a3951064baaf4952f596e9e/stl/src/sharedmutex.cpp#L20-L22

Even more with XP compatibility break, when InitOnce... stuff will be called statically.

Still open questions:

1. Safety of this optimization. I'm a bit concerned about unloading module that is forwarder target. It will be not a problem for Kernel32.dll, which does not ever unload, likely to be no problem if module is imported normally as well, but generic case is still a concern, so need to figure out limitations
2. Using .def files, does is cost start using def files everywhere (as a possible #613 resolution), or maybe mix def files and __declspec(dllexport)
3. Need to be careful with signature and calling conventions. This way likely to be ABI breaking to tune types and calling conventions.

Start with the cited fast-path synchronization code in stl/src/cthread.cpp and stl/src/sharedmutex.cpp, then read the linked Microsoft DLL export-forwarder documentation. Investigate forwarder safety during module unloading, the use of .def files versus __declspec(dllexport), and ABI or calling-convention constraints. Done requires an agreed scope and documented limitations before changing the exports.