The general rule is as follows: A class name as a string will always be looked up fully, even if the class name gets shadows by another variable because strings are not identifiers.
It is only class names as identifiers that must obey the rule that if it is not known yet or hidden by something else that it may not be found to ensure that the older variable does not take over the name if it gets reused.
If a later module reused an existing name for a different class or struct type, this new name would completely shadow the old one, even in the base files.
Changed it so that each compilation unit (i.e. each ZScript and DECORATE lump) get their own symbol table and can only see the symbol tables that got defined in lower numbered resource files so that later definitions do not pollute the available list of symbols when running the compiler backend and code generator - which happens after everything has been parsed.
Another effect of this is that a mod that reuses the name of an internal global constant will only see its own constant, again reducing the risk of potential errors in case the internal definitions add some new values.
Global constants are still discouraged from being used because what this does not and can not handle is the case that a mod defines a global constant with the same name as a class variable. In such a case the class variable will always take precedence for code inside that class.
Note that the internal struct String had to be renamed for this because the stricter checks did not let the type String pass on the left side of a '.' anymore.
- made PEnum inherit from PInt and not from PNamedType.
The old inheritance broke nearly every check for integer compatibility in the compiler, so this hopefully leads to a working enum implementation.
- load internal shaders only from file 0. This does not contain aborts, like most of the other checks,but it will now refuse to load any core shader file from anything but gzdoom.pk3.
Issuing take CCMD no longer causes assertion failure at src/scripting/vm/vmexec.h:662
assert(numret == C && "Number of parameters returned differs from what was expected by the caller")
This serves no purpose, there's not a single place in the code which checks for it, but if that negative values goes unchecked to functions that expect an actually meaningful value for damage inflicted, some bad results can happen. If no damage is inflicted, a proper 0 needs to be returned so that the value can actually be worked with. The return value was a ZDoom invention, it is completely unclear why -1 was chosen if some kind of protection rendered the damage ineffective.
