[pull request] Introjucer MultiPaint Document

Very often I design components in the Introjucer that need to change their look a bit depending on how they are used. 

For example, I recently needed a volume/mute/solo speaker element with a small icon of the speaker. Now obviously this will have a different background design for every speaker, yet it will still have the same components and the same layout. 

Or for example I'm selling a "lite" version of one of my audio plugins. In that version, I remove some sliders&buttons programmatically. But I also need to update the background layer to make sure there is no labels for non-existent GUI items.

And also for completly custom GUI controls (like a panner, for example), I often need different background layers. In case of the panner, for showing different speaker arrangements below the panning grid.

So to make my life easier, I introduced the "MultiPaint" jucer document. You can simply open up a regular jucer component c++ file in a text editor and in the XML change documentType="Component" to documentType="MultiPaint". Afterwards, you'll have a new text box on the Class tab in jucer, called "Paint Variants". In there, you put a comma-separated list of variants and then the Introjucer will show you one background tab for each variant, and generate paint code for all of them. 

The only thing you then need to do to switch around the component's background at runtime is to declare a paintVariant String variable that is visible in the paint method. 

Patch is attached.

Thanks for the request though I don't think we'll take this one.

The main issue is that if I was going to implement a really good solution to the problem of having different paint routines in the component, this isn't how I'd approach it. The "correct" approach would be to have a new type of file which would effectiveley be a free-standing paint routine - i.e. basically a class (but not a Component) that does some drawing, and which can be used by a Component in its paint routine. Then you could build as many of these as you liked and the UI editor could swap them out for you. However, writing that would be a load of hassle and we don't have time to do it! But.. I'd be reluctant to add a simpler but more short-term solution like yours, because then we'd need to keep supporting it forever. Ah, the joys of software design..