WIP TVB-2757: Add runtime filters for linked datatypes

[VinczeRobert]

I wrote an incomplete solution for this task trying to build on what we already had with the user defined filters. So we can say that there are 3 types of filters:

1. "Implied filters" which are written in the code and can't be changed
2. User defined filters (added and applied by the users through the UI)
3. Runtime filters (where the value of the filter depends on some other value(s) from the UI)

We handled the second type of filters in TVB-2428: #189. To apply both 1) and 2) filters there we added the 1) filters in the same HTML structure as the 2) filters as hidden fields so they can be handled in the same way. When the user hit the apply button the list of fields, operations and values was sent through an Ajax call to get_filtered_datatypes. There a new select field is created with the new conditions and then when we get back to JS, the field is redrawn by applying both types of filters.

For the runtime filters we have two types of fields, which I like to call the trigger fields and the triggered fields. A change of the value of a trigger field would mean that the possible values of the corresponding triggered field(s) should change. For example in the Connectivity Viewer if we change the connectivity then the node colors and the shapes diemnsions (which are ConnecitvityMeasures) should change such as their fk_connectivity_gid value should be equal to the gid of the chosen connectivity.

The big problem is that there are more complicated filters. For example, in the Connectivity Annotations Viewer page the change in the Ontology Annotations field should mean the connectivity values are changed and then based on the connectivity values the region mapping should change too + if you choose a connectivity and no region mapping, the viewer launching fails. Here you change the onthology but the connectivity doesn't have an "fk_onthology_gid" field, it's vice versa.

So what I tried to do for runtime filters is to return a dict where the key will be part of the div's class in HTML and it will give information about how to apply the filter and the value is the FilterChain object. Since the value part of the FilterChain will be replaced at runtime, I used it to store the index class of the select field that the filter should be applied on.

Another problem is that the runtime and user defined filters should be applied at the same time, which currently would not work for every situation. Also let's say we add a user filter, then we trigger a runtime filter... should the user filter be applied as well even if the user did not press the apply button. If not, then what happens? Let's say we applied the filter and then we trigger a runtime filter, should the effect of the applied user filter stay or dissappear and would reappear only if pressed again?

My partial solution I think is too complicated but it shows us the things that we need to think about when solving this task and it could be a starting point to something simpler.

[popaula937]

Closing this because PR #351 is a more clear solution