Rethink computables recalcuation resolution

[medikoo]

/cc @kamsi

Currently on incoming data batch, following happens:

1. Static (non-computable) records are put in place. If some record changes state from non computable to computable (may happen if some object got back from destroyed state to I'm here again state), it's also immediately recomputed.
2. All computables that depend on statics are recomputed
3. All computables that depend on computables are recomputed (and so on)
4. Events for boths statics and computables are propagated

There's an issue with resolution of new computables in first step, there's a risk they may approach uneven state. Technically that should be put between step 1 and 2.

At this point I've introduced a fix that forces another re-computation of them in step 2.

[medikoo]

Additionally we should make more bulletproof computables resolution, where multiple objects are involved.
e.g. in ELS we have a case, where applicableSubmissions resolve both submissions of user and representatives. There's a getter, which accesses each applicable submission. When representative is removed. This getter is run before applicableSubmissions are updated, and therefore is provided with dead submission (base type) objects.