pdb hook: support static libraries

[jcar87]

Currently the PDB hook (the hook that copies PDBs into the package folder) will only work well for shared libraries, not for static ones.

Our current understanding:

PDBs are created by:
a. The compiler, when using /Zi - when generating obj files.
b. The linker, when creating .dll or .exe files. Our understanding is that when static libraries are linked into a DLL or an exe, the linker looks for their PDBs, in order to generate a "new" one.

PDBs are consumed by:
a. The windows debugger
b. The linker, when creating .dll and .exe from object files / static libraries that have pdb information - ( see point .b above - the linker both reads and aggregates pdbs)

For a static library, the .obj files inside them will have a reference to a .PDB (a full path). Note that a single static library may have object that reference multiple, different PDBs.

Thus, crucially: the debugger will only attempt to load PDBs from shared libraries (.dll) or executables (.exe), and at that point it has no notion of static libraries. For static libraries, .pdbs inside a Conan package would only be consumed by the linker when generating a .dll or .exe.

The documentation of the linker says this (note that the default is /DEBUG:FULL

The compiler's /Z7 (C7 Compatible) option causes the compiler to leave the debugging information in the object (OBJ) files. You can also use the /Zi (Program Database) compiler option to store the debugging information in a PDB for the OBJ file. The linker looks for the object's PDB first in the absolute path written in the OBJ file, and then in the directory that contains the OBJ file. You can't specify an object's PDB file name or location to the linker.

When consuming a Conan package with static libraries:

• the full absolute path to the .PDB written in the .obj may no longer or exist, unless the package was generated on the same computer
• the .obj is also unlikely to exist, as packages only contain the reusable products (the static .lib files)

However, the msvc linker reference, specifies the following:

LIB, if defined. The linker uses the LIB path when it searches for an object, library, or other file specified on the command line or by the /BASE option. It also uses the LIB path to find a .pdb file named in an object. The LIB variable can contain one or more path specifications, separated by semicolons. One path must point to the \lib subdirectory of your Visual C++ installation.

It may be then be possible for the linker to try and locate .pdb files in the LIB environment variable, and it would appear to be a contradiction. If the linker can indeed use this environment variable, we may have some luck.

Some other things to consider:

• it needs to be determined whether the linker will try and find in the LIB env var if the path to the .pdb is a full path too, or if it only does this when only a filename is known (I suspect this needs to be controlled at compile time)
• when we specify /Zi to the compiler, but don't specify an output name for the pdb, the compiler uses a default filename. I think it uses some serial writting to that file for multiple compiler invocations, so it "adds" data to it - but if different libraries in different packages use this fallback name, then we may not have ways to disambiguate this in the linker. Observed these are problematic in projects that use autotools and build with msvc