[Feature] - Replace bindingsConfig.yml FunctionBindings with direct manual P/Invoke

[smaillet]

Is your feature request related to a problem? Please describe.

NOTE:
Feature requests are intended to request a new feature or a change in the intended/designed
functionality (a.k.a. DCR). They should not be used to report bugs, which are incorrect
implementations of the designed functionality.

Editing and maintaining the bindingsConfig.yml FunctionBindings section is tedious and error prone, While there are a lot of validations built into the LlvmBindingsGenerator it's a completely foreign language to generate C#, an arguably non-foreign language). It is likely simpler to just express those manual marshaling constructs in actual C#. The functionBindings section is basically just P/Invoke signatures in a weird language... which makes it harder to maintain.

Describe the solution you'd like
Tooling can generate a single p/invoke file from current FunctionBindings to eliminate the tedious creation of such a file, which is then maintained manually after that. Then, once that is created from the FunctionBindingsTable, then most of that part of the configuration file is removed/replaced with a simpler list of "manually managed interop" functions. With the rest auto generated. This allows for auto generation on many of the APIs, and only the parts with ambiguities needing manually declarations is actually maintained (and in a familiar language to start with).

Now that the bindings generator works in .NET Core, this entire process could move to a compiler source generator. This would allow the tool to perform validation, including the manually edited parts to ensure nothing is missed as it does now, while only generating for things that are non-ambiguous. The HandleMap, AnonymousEnums, and IgnoredHeaders sections can remain in the configuration file as they are pretty straight forward and easy to understand.

Describe alternatives you've considered

1. Entirely manual, which is what existed before the LlvmBindingsGenerator was created, which is not very desirable.
2. Maintain a separate executable and run it as part of the build scripts, while we have that now, it requires assitional steps that is more difficult to manage. (The build is complicated enough for interop already, so anything that can simplify it is good)

Additional context
Building things into the compilation process gives greater options for validation AND helps set the stage for doing this part of things for multiple platforms.

NOTE
This isn't a total reversal to doing it all manually. It's a realization that some of it is generatable but other parts require intervention and that the best way to do that is in the target language C#. So the tool will need to understand that code to detect redundant P/Invokes of things removed, new APIs, not yet covered, as well as validate signatures of the methods still match the latest LLVM versions. (It does this now based on the YAML config information so that needs extension to Roslyn syntax trees instead). Thus it's a move towards a hybrid approach with the tooling analyzing the manually maintained code to report any issues with it. (Thus, hopefully, eliminating the error prone part)