Fix use of categories versus representations

[fingolfin]

A category should normally not imply a representation, but this packages does this a lot, e.g. here:

DeclareCategory("IsSkewbrace", IsAttributeStoringRep);

This code means that any skewbrace type from now on must be in the IsAttributeStoringRep representation. So if I wanted to implement a nice skewbrace subtype myself, I couldn't -- at least not while staying compatible with your package; or else I'd have to come up with my own "name" for the concept, such as IsAnotherKindOfSkewbrace.

Instead, there should be a category which carries the mathematical implication, and a representation, which implies the category. Something like this (we also add IsDomain in, as a skew brace is a "domain" in the GAP sense of the word (i.e., a collection with an algebraic structure).

DeclareCategory("IsSkewbrace", IsDomain);
DeclareRepresentation("IsSkewbraceRep", IsSkewbrace and IsAttributeStoringRep);

(Of course IsSkewbraceRep isn't quite nice either, as it blocks that name for a very peculiar representation, but at least now others can also use IsSkewbrace sensibly).

I guess one might even want to do more, and throw in IsMagma or some such, but that's a separate issue.