Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
...as soffice.exe creates the proper environment (PATH) for soffice.bin to be
able to load URE libs like sal3.dll, so soffice.exe itself should neither be
able to load nor depend on sal3.dll (and does not depend on anything exported by
it, anyway).
It is unclear to me how this ever worked (which it presumably did?) with any
Windows build, either native MSVC or cross-compiled MinGW. (Maybe MSVC builds
do not record a dependency from soffice.exe to sal3.dll, noting that the former
does not import anything from the latter?)
