redecide on whether or not Criteria should be implemented via classes

[kukeiko]

in #58 I've decided to go for classes. Back then I felt like it is the more convenient option overall. Now I think it is only convenient while still figuring stuff out. I'm certainly not done with figuring stuff out; but I feel like it has become too convoluted. the various implementations (InRange, InSet, Or, And, Named, ...) create a nasty nest of co-dependencies to each other. It just feels wrong at this point.

So I'd like to give it some thought and possibly go back to using plain old JS objects instead.

One thing to consider that severely nags me: even if we go with plain old JS objects, we still won't have flawless JSON parsing/stringifying unless we move away from InSet/NotInSet having Set instances - which are used for moar performance (and I am convinced that this is an absolutely necessary optimization, as a linear lookup through an array is gonna take ages).

[kukeiko]

I am now of the opinion that they should stay as classes, but we're instead introducing proper interfaces to:

• resolve the rats nest of cyclic imports
• remove the instanceof checks

[kukeiko]

At this point in time I am confident that class based implementation is here to stay for the foreseeable future. To clean it up I fixed the 2 previously mentioned issues while working on #202 :

resolve the rats nest of cyclic imports

fixed by using interfaces instead - each type of criterion has its own interface that is used by everything else; the concrete class itself is only ever imported by another, new class that contains utility methods related to criteria (currently named EntityCriteriaTools).

remove the instanceof checks

also fixed by having each criterion interface require the existence of a unique Symbol - instanceof checks are replaced with "does this object contain that unique symbol?". those checks exist as methods on the EntityCriteriaTools class.

[kukeiko]

Reopening as I now once again tend to moving criterion math logic out of the individual classes to make the code more mantainable

[kukeiko]

Criteria are gonna stay as classes and I am now in the process of moving the logic outside of them. Also cleaning up the various over-engineered interfaces & symbols I added.

I am also trying to achieve compile time safety for any operation missing for a given criteria type or combination of 2 criteria types, got it working for inversion already.