I am absolutely uncertain about this pull request, the underlying mechanisms for this library functionality is still an enigma to me.

What I seek to achieve:
I am still working on the SDL3 bindings. Some of the classes in SDL3 contain fields which are of primitive types (uint32_t) but actually represent enum types. C enums being weakly typed bla bla bla. I would like to map these specific fields (which I hand pick) to the corresponding enum types. For this purpose I thinkTypeMappers are the tool of choice. I have already established similar functionality for function parameters of primitive types that represent enums. I simply collect allParameters and their correspondingType in a dictionary and check that when marshalling.

Trying to replicate this same approach for fields has presented me with the problem that the context that is provided to aTypeMapper is not able to decide whether it's a field that should be mapped. There is very minimal information given, no ability to derive a corresponding class or anything of that sort.

Modifying the library to make what I desire work is fairly trivial. I check for the property inCSharpSignatureType (not the field!) and for the field in the marshalling methods (it's the only thing that's provided respectively).

Alternative approaches I've considered:

• Changing the field's type inPreProcess and dealing with the marshalling properly via aTypeMapper for the enum
  • Causes a stack overflow for some reason
• Changing the property's and internal classes field type inPostProcess
  • I can't seem to be able to find the inner__Internal class

Now, the considerations for this pull request:

• TheParameter field does not actually seem to represent a concrete method parameter, it can be different things for different contexts. Sometimes it's not set at all, other times there's a degenerate version newly created from a differentParameter that has a different naming scheme. So all in all I feel like this PR is not line with the original design intent here (because I currently don't think I understand it).
• While I only requireField onTypePrinter andProperty onTypePrinterContext I have also decided to include both of them in both classes, as well as an additionalMethod field that could be helpful when trying to recreate the desired functionality for return types.
• TypePrinterContext'sField property goes unset.
• Variable is another often-seen class that could be considered for addition. I have decided to exclude it because I cannot see a direct use for it.

I actually hope that what I seek to accomplish can be accomplished using existing library mechanisms, I guess this would've been more fit for an issue asking for help, but I think it might be worth presenting the code here for consideration anyways.

If this PR were to be considered for merging it would definitely require a second closer look by someone with a deeper understanding of the library. It's highly probably that I missed spots for potentially providing the new fields and other times I have provided them needlessly at the very least.

To conclude here's a minimal example that demonstrates what I seek to achieve:

#include<cstdint>typedefenum {    A =0, B =1, C =2} MyEnum;classMyClass {public:uint32_t member_enum;uint32_t member_normal;};

I wantmember_enum to have typeMyEnum on the C# side andmember_normal to remain asuint32_t/uint.