Distinguish between structural and semantic interpretations of automata

[mtf90]

This PR introduces the concept of semantics which allow one to distinguish between the structural and semantic interpretation of automata. On an abstract level, it introduces various semantics providers in the net.automatalib.semantic package (automata-api) to establish a standardized way of expressing semantics. However, for the most time, this interface is not yet used in AutomataLib. Instead, many of the inherently finite formalisms (DFAs, Mealy machines, etc.) provide custom FiniteSemantics sub-interfaces that combine their own interface with a semantics provider. For these formalisms, the state structure can be directly accessed as before which allows us to skip the need for refactoring in many places.

Along these changes,

• SEVPAs have been adjusted to the structure/semantics split by now implementing the UniversalAutomaton interface for structural properties and providing DeterministicAcceptorTS semantics to express their acceptance behavior.
• IntAbstractions (including sub types) have been moved to the net.automatalib.automaton.abstraction package (automata-api) alongisde their default implementations in order to de-clutter the original automaton definitions.
• Some places have been tidied up.

[mtf90]

@fhowar One thing worth discussing is the random generation of automata. Currently, it only works for FiniteSemantics because many methods offer an optional minimization step (which in turn requires finite semantics). I would be open to dropping minimization support and opening it to any random structure. IMO, minimization can be easily achieved in client-code if needed, and offering "minimization support" during random generation may falsely suggest that we are generating minimized automata of a given size, which we do not.