Consider using ObjectDebugSession for PDBs as well, not just for mach-O and ELF

[mstange]

To iterate the list of public symbols and the list of functions, we currently have two implementations:

• For mach-O (macOS) and ELF (Linux & Android), we use the code in elf.rs which makes use of symbolic's ObjectDebugSession APIs.
• For PDBs (Windows) we have our own code in dump_syms.

It would be nice to use the symbolic implementation for everything. One advantage would be that I don't have to implement #280 twice - the elf.rs implementation from #392 would just work for Windows if PDBs went down the symbolic code path.

[mstange]

This naive patch to send PDBs down the shared code path points out the following differences:

• The parameter size for FUNCs on x86 is now always zero. I think this might be an acceptable regression: In all the x86 .sym files I've seen, there is a STACK WIN entry for every FUNC address anyway, and rust-minidump prefers the parameter size from the STACK WIN size in that case. See FUNC and WIN STACK entries disagree on parameter size #284.
• All FUNC m and PUBLIC m records lose their m. I think this means that symbolic is de-duplicating symbols and functions at the same address before it yields them from the iterator. This needs a little more investigation. This is because elf.rs doesn't correctly set is_multiple to true when it encounters multiple symbols at the same address. I'm fixing it in Make is_multiple work properly in elf.rs. #416.
• Most FUNC entries are missing their argument list. This is Some pdb functions are missing arguments getsentry/symbolic#423.
• Many FUNC and some PUBLIC entries are missing entirely. These might be "thunk" or "sepcode" symbols. The missing PUBLIC entries are because those have public_symbol.function set to false, and symbolic filters those out. The missing FUNC entries are indeed SeparatedCode symbols. I'm fixing the FUNC part in Add support for SeparatedCode symbols. getsentry/symbolic#622 and I'm not sure what to do about the PUBLIC part.
• Demangling of PUBLIC symbols is a bit different (extra public: prefixes, for example)
• Some FUNC function names have an extra leading underscore. I think these underscores are actually correct and our PDB code just is a bit overeager when demangling FUNC names.