WIP #139 attempt4 --- Implement pseudo-compound-classes.

[Tasqu]

Since Spine-DB-API and SpineOpt both support and aim to use "superclasses" and "compound classes", SpineInterface needs to support them as well. Unfortunately, "true" implementation would have required deep renovations of SpineInterface structures, which I couldn't pull off without demolishing a lot of code optimization by @manuelma, essentially murdering the performance and usability of SpineInterface. Thus, I had to implement "pseudo-compound-classes" to replicate the required functionality with minimal impacts to performance critical parts of the code.

In essence, superclasses function similar enough to their Spine-DB-API counterparts:

• They contain a list of their subclasses, but hold no entities of their own (I don't think I actually enforced this in SpineInterface, though?)
• When a superclass is called, that call gets passed to its subclasses, their output is merged, and finally returned.

However, "pseudo-compound-classes" work quite differently to their Spine-DB-API counterparts:

• SpineInterface doesn't allow EntityClasses as dimensions of EntityClasses, so instead:
• The original compound class gets converted into a superclass.
• A set of automatically generated subclasses are generated for every possible combination of dimensions (named <superclass_name>__<byclass1>__<byclass2>__...)
• This replicates the functionality of a compound-class, but not its structure.

Considerations:

• You might not be able to write superclasses into a Spine DB correctly, as I didn't really test this as it wasn't required for SpineOpt.
• You definitely can't write "pseudo-compound-classes" into a Spine DB correctly, as they are handled differently in SpineInterface.

Fixes #139

Checklist before merging

• Documentation is up-to-date
• Unit tests have been added/updated accordingly
• Code has been formatted nicely
• Unit tests pass
• WILL NEED A VERSION BUMP POST-MERGE!