Added LanguageConfig concept, implemented function_macro_prepend option

[pixsperdavid]

In order to allow easier customisation of generated header files on a per-language basis, I've expanded the Language enum to contain a per-language configuration (CLanguageConfig, CSharpLanguageConfig, etc.), which is then propagated to methods of HeaderLanguage implementers. Consequently I have renamed Language to LanguageConfig to better describe this new function.

The first config option I have added is based on my query in #202, which allows optional insertion of a custom macro text before each function definition. There's a good deal of other potential config options I'd like to add but holding off until I get approval on this approach for adding the LanguageConfig struct to contain and distributed this.

[danielhenrymantilla]

Thanks! I had something like that in the back of my mind, but never got to implement it (I have a slightly more dynamic/extensible idea using "the Provider pattern" (don't have the time to look up a link right now; it was suggested around the Error trait in the stdlib but rejected there, even though as third-party libs we can roll our own).

• My goal longer-term is to get rid of the idea of an enum of languages altogether, and just have a whole trait API define how to render headers for a given language or language style, whilst also having, at the other end of the pipeline (at the "generate headers call"), a way to smuggle config info which the "language"/specific trait implementation could dynamically query.

But since the current code does hard-code C/C# branches, the version you are currently offering is definitely a great fit!

---

Since this a rather major PR, I will wait a bit to be testing it on other codebases and whatnot, but if in 2-3 weeks I haven't come back to this, do ping me, and we'll work on merging and releasing it 🙂

[pixsperdavid]

My goal longer-term is to get rid of the idea of an enum of languages altogether, and just have a whole trait API define how to render headers for a given language or language style, whilst also having, at the other end of the pipeline (at the "generate headers call"), a way to smuggle config info which the "language"/specific trait implementation could dynamically query.

I attempted to try and hide the LanguageConfig structs within the HeaderLanguage trait implementers, but it would mean adding fields to them which felt like it would be a more major structural change. Definitely something to aim for in the future though.

[pixsperdavid]

@danielhenrymantilla I've updated this PR for recent changes, do you have time to look at merging?

[pixsperdavid]

Is there any kind of testing I can do to help expedite merging of this PR? I have quite a few other formatting features I need to build off this which I'm hesitating to add at the moment as they're only going to make it larger.

[pixsperdavid]

Due to development urgency, I've unfortunately had to move to another solution so can't maintain this PR going forward, happy to pass to anyone else if they would find it useful.