Propper Mapbase port, with quality-of-life improvements

[Unusuario2]

Since the Mapbase tooling supports Propper integration, it makes sense to redistribute it and create a custom version of the tool with improvements. These changes primarily benefit coders, as Propper shares a significant amount of code with VBSP, making the original source code difficult to work with. There was no clear separation between Propper and VBSP, which made understanding the overall structure challenging. Additionally, the code followed a personal format rather than the standard Source engine format. To address these issues, all VBSP-related code was either removed, relocated to separate files or deleted (if not used).
The Propper VPC script also has gotten improvements, now all the VBSP code will be in Vbsp Source/headers Shared Files.

The code was extracted from: https://github.com/tuxxi/propper-2013

Code base changes:

1. Unused VBSP code has been removed.
2. Legacy VBSP code (not required for Propper but necessary for compilation) has been moved to propper_garbagecollector.cpp/.h. For more details, read the comments in propper_garbagecollector.cpp.
3. VBSP and Propper now share a unified codebase.
4. Propper-specific code within the shared codebase is now enclosed with #ifdef PROPPER to prevent contamination of VBSP.
5. Minor string cleanup.

Note: If merging this PR add credit to Carl Foust (creator),1upD (Mapbase shader fix) and tuxxi for fixing compilation in SDK Base 2013.

---

PR Checklist

• My PR follows all guidelines in the CONTRIBUTING.md file
• My PR targets a develop branch OR targets another branch with a specific goal in mind

[newgreenshoot]

Is there any reason to use this version of Propper over the built-in reimplementation in Hammer++? I'm a little worried this might already be obsolete, and not worth maintaining.
https://developer.valvesoftware.com/wiki/Hammer%2B%2B/Propper%2B%2B

[Unusuario2]

Since Hammer++ ships with its own version of Propper, it doesn’t make much sense for Mapbase to include Propper i guess.

This version of Propper is outdated compared to Propper++, but since Propper++ is not open source and Propper itself has a large amount of shared code, working with it can be difficult. Some users (myself included) run a custom Propper compiler with its own FGD and modifications. Including this code in Mapbase would benefit these users, as it provides a clean, pre-configured build that works within the Mapbase environment.

[Cvoxalury]

Is there any reason to use this version of Propper over the built-in reimplementation in Hammer++? I'm a little worried this might already be obsolete, and not worth maintaining. https://developer.valvesoftware.com/wiki/Hammer%2B%2B/Propper%2B%2B

Simple, not everyone uses h++. It's always great to have a valid alternative such as standalone Propper. I can personally say it benefits me.