Extension based ribbon contribution

[johntyree]

This is a prototype for how we might extend the ribbon from PyXLL extensions.

There's a bit of a hacky workaround with the config right now, because PyXLL parses it prior to loading extensions and then doesn't reexamine the ConfigParser object.

We have to specify two files, a default_ribbon and the normal ribbon. The default_ribbon is really just the old ribbon file and serves as a starting point. Then the extensions all submit their fragments to be included and they are combined by the extension loading code. Finally, we write out the new complete to ribbon xml to whatever file ribbon is set to, since PyXLL is hardcoded to load that.

It's not beautiful, but it works nicely.

This PR doesn't handle layout whatsoever. We have no control over the order in which extensions are loaded and there's no effort here to try to order the fragments smartly. If they extension submits a new tab it just goes at the end of list. If the extension submits an tab that matches an existing tab, the groups just get appended to that tab. If one knows the names of all the fragments, one can ask for them to be combined in a particular order, but there's no easy way to know right now.

The API might be nicer if we extract the element ids as the name rather than make the extension pass it in, which can be error prone. I'm not sure about this yet.

[johntyree]

xref: #6

[dpinte]

@johntyree it looks good to me as a first implementation. @tonyroberts any thoughts? Or shall I merge?

[tonyroberts]

@dpinte sure, looks good to me (except the dead cat, poor animal!)

[dpinte]

;-) merging

[johntyree]

Did I add that cat picture? Yikes. I'm sure I must have had plans to update that...