Refactoring of BuildTools/Common/Profile

[HurricanKai]

This will need quite some refactoring to propperly work with C# 8 Nullable, to guarantee non-null values everywhere.
For now (in #40) everything is set to some default value, but this could lead to some unexpected behaviour (for example, if for whatever reason ClassName isn't set, a class with an empty name will be generated, which means invalid generated code.
Low priority, as it works, but when working with this code, consider refactoring it, or at least take care.

[Perksey]

This is rough, as binder JSON was designed in a way that null was actually an acceptable value for most things. Moreover, we have people working on external converters so we can introduce a wider range of APIs to Silk.NET.

Keeping the binder up-to-date has never really been a focus for us, as we were kinda hoping to just leave it to do its magic once it's working. As such, I don't see us making extensive changes because, as you said, it works!

We'll consider this for a future breaking release, maybe a 2.0.

[HurricanKai]

Perfect, that was the intend. Just wanted to leave this here for anyone to find that will be working on it. No need to invest time and effort if nothing needs changes anyways

[Perksey]

As of preview 4, we will no longer be maintaining our own bindings generator, as we'll be rewriting the generator and moving it out into its own product - SuperBind - under the SuperTools umbrella.

[Perksey]

As of preview 4, we will no longer be maintaining our own bindings generator, as we'll be rewriting the generator and moving it out into its own product - SuperBind - under the SuperTools umbrella.

This has changed, but I don't really think the refactor is needed to be honest. I don't want to mess with the BuildTools unless I have to tbh, so I think I'm gonna close this and the other issue as well. Thanks for the suggestion though.