Add a sane and clear extension API

[fingolfin]

Right now sglppow and SOTGrps "hack" into the smallgrp internals in order to extend it with additional layers.

This works, but is brittle, and highly non-trivial to do for 3rd parties who may wish to provide similar extensions. It also introduces questions about order dependence (i.e. if sglppow is loaded before or after SOTgrps may affect in which "layer" they go) that are difficult to resolve in the current setup.

It would be good to have a sane API for adding "layers". This could even be used by the "internal" layers, which are currently interwoven quite a bit.

Then the ordering problem could be handled by e.g. allowing to assign priorities to layers; as long as sotgrp and sglppow use different ones (mutually agreed) their loading order becomes irrelevant (granted, it probably is already because they don't overlap; but other extensions may not...)

[fingolfin]

To be clear: the existing layer system as such is great in principle!

What I object to is the ubiquitous use of "magic constants"; you just have to know what layer, say, ID_SMALL_GROUPS_FUNCS[12] belongs to. And worse, some of these helpers are used across layers. But then why even store this in a list, why not have a helper, say, SGL_IdForGroupsWithPropertyXYZ or so?

[fingolfin]

I guess an important first step would be untangle the layers; make it very clear which function belongs to which layer. Functions that are shared across layers should have a dedicated name, and not be an entry of an array of functions.

And of course we need to be careful to not break SOTGrps and SglPPow. In an ideal world, we'd make our changes in a way that old SOTGrps and SglPPow stay compatible; then update SOTGrps and SglPPow to be compatible with both the old and new interface. And then after some time drop the old interface.

But that may not be possible, at least the first part (providing both old and interface here). But it should be possible to have SOTGrps and SglPPow support both. Then the plan would be to do that, and release both packages; and then afterwards release a new SmallGrp with the new interface. And make sure that old SOTGrps and SglPPow versions will raise an error when loaded with that new SmallGrp (no silent breakage, those are the wors)

(Beware: there may be other package trying to integrate into SmallGrp...(