Generated SDK does not compile

[Cre3per]

To make testing and using the generated SDK easier, source2gen could

• (1) Add dummies for missing types that aren't registered in the schema system, e.g. CHandle, CUtlVector, and many more.
• (1) Add a dummy interfaces namespace used to access static fields
• -(2) Take into account template arguments when sorting class definitions- we're no longer sorting types
• Fully qualify template argument names and include required modules (Assumes Dump types per module #58 is merged)
• Translate built-in template argument names to C++ types, e.g. CUtlVector<int32> -> CUtlVector<std::int32_t>
• Don't forward declare nested types, because that doesn't work in C++
• Rename nested types to use underscores
• Generate static_assertions to make sure the generated types have the layout we expected
• Use large integer types for consecutive bitfields with entries crossing byte borders (e.g. char a: 7; char b: 2)
• Detect misaligned fields and types and replace them with dummies
• Replace template types with non-type template parameters with dummies (e.g. CUtlLeanVectorFixedGrowable) (because those parameters are not included in the sdk)

This list grows as more issues surface

(1) The user can replace the dummies with real implementations if they want to access the affected types. To compile the SDK, dummies are enough
(2) This requires an update to the ordering algorithm to detect indirect cyclic dependencies, e.g. player->entity->world->player

[Cre3per]

I'd like to work on this

[Cre3per]

I am at a point where the generated SDK compiles.
Putting in a little more work to generate static_assertions and making them pass so that the SDK is guaranteed to work in user projects.
Most of the offset/size mismatches so far were caused by wrong padding size. Currently working on respecting field alignment when generating pads.

[Cre3per]

The SDK now compiles and all generated assertions for type sizes and field offsets are passing.
Will clean up the code before filing a PR.

[Cre3per]

Open non-blocking worries

• All fields with template types are replaced with dummies
  • because we cannot detect if a type has non-type template parameters
  • we could add a whitelist of known-good template types, but that'd be manual work
• There are no more private fields, even pads are public, to have standard-layout-classes

There are also new limitations, some types/fields get commented out, see README.md. They don't make source2gen worse though, as previously source2gen simply generated broken types for affected classes.