Clean-room reverse engineered SDK headers, part 1

[freed00m21]

Partially resolves #63

[nekonomicon]

We have such macro:
https://github.com/FWGS/xash3d-fwgs/blob/master/common/xash3d_types.h#L51

[SNMetamorph]

Nice work! Though, it's very helpful in terms of licensing issues

[a1batross]

I'm not sure that clean room means generate data types from DWARF. But it's better than nothing.

I would add static assertions on struct sizes though, at least for ILP32 model (aka 32-bit). It does not guarantee compatibility, but again better than nothing.

[a1batross]

As far as I remember, compatible dlight struct can be taken from Quake.

[freed00m21]

I made changes, is anything else required?

[a1batross]

As it builds now, I should check it that nothing potentially got broken, and then merge it. Thanks.

[a1batross]

After all, I'm quite suspicious if clean-room definition applies to the generated code from DWARF debugging information.

Not only that, it's also weird that preprocessor variables only got refactored into the enumeration, retaining same names. Preprocessing is only the first stage of compiling C code and while some of it information gets preserved in debugging info, like included files, the defines unfortunately do not and I don't know any other sources of information where they could be taken from.

[SNMetamorph]

@freed00m21 i need to clarify some things, so I have some questions for you:

1. Have you even been familiar with Xash3D or HLSDK source code before doing this pull request?
2. In your code we found things that couldn't be obtained directly from binaries, as some bit flags, like FBEAM_*.
   Where did you get these data? It's ok as long as it's obtained from some another clean-room reverse-engineering project, so we need to know exact source of that data to be completely sure.