Now we again have a dev and prod variant and the user needs to run 'make 
init-dev-config'at first time setup.

resolves https://github.com/iqb-berlin/testcenter-frontend/issues/247

Why? Consider the following scenario before this change: we have 10 test-sessions prepared but 7 testees are present. The autoCheckAll-mode is on. We click pause and `pause` is sent to all ten test-sessions. The seven session which are online go in the pause mode and the controller sends back the state `{CONTROLLER: paused}`. Now we hit `resume` - and reach the only seven test-sessions which are in pause now. Now one of the the remaining three testees shows up and starts his session. Ge gets the pending pause from before command but no resume. Now he is paused, while the rest isn't.

To avoid this case of inconsistency we send the resume command to all test-sessions anyway.

Another approach would hve been to drop the command-"caching" for pending tests. But this would have other impacts in scenarios where testees who start later.

changes the selection/check behaviour so, that after a block is selected (the first time) the checked sessions are kept and the clicked one is added if not there

makes the toggle between all-of-type and only-this-row selection ( = spreading) only happen when clicked on the very same session

changes back the the click-selection-order: first click on a block selects the test only, seconds selects all tests of the same species.

Why? To select all at first was an idea to make it easier for popele who don't understand that they have to select tests. But those are covered by the selectAll-Testmode now. So we can return to the previous behaviour which we consider to be more intuitive.

In the frist implementation of the group-monitor the test-sessions replaced a combination of person and test so they needed there own id. Now, they represent only tests and we don't show a person which is a logged in but has not started a test right now anymore, we don'T need the combined id anymore as well.

renames the testMode-option "isMonitorable" to "receiveRemoteCommands", since it means precisely that and to distinguish it from the backend's mode capabality 'monitorable'.

removes any affection of the superState by the the testMode since the only testMode which are monitored currently are hot.

makes the testController only connect to commands-stream if the testMode has the new capabillity `isMonitorable`

fixes a bug which made tests in modes without saveReponses to write back some data when test with saveReponses was opened before.

Explanation: The testmode comes later with getTestData and is set correctly in the RUNNING stage, while in LOADING stage it war still the testmode of the test before! So if we opened a test in TRIAL mode after running a test in HOT mode, the loading stage will be write back to backend. As a workaround, we reset to DEMO here, so while in loading stage `saveResponses` is always false.

As all tests of one login are always in the same mode, maybe it would be better to retrieve the testmode from the login instead by getTestData.

extends filterSessions ba the capability of filtering by superState and bookletSpecies and adds unit tests.

most of them occured because of missing dependencies in the testingModule, some where console-outputs from backends.services (which are mocked now)

which does not make anymore sense, since we can only only jump to top-level testletes ( = blocks).

At the time the stats for checked sessions where updated, the main sessions object was not updated, so the number of checked sessions where compared with the number of sessions during the last change. At the first time the previous number was always null.

radically simplifies the getCurrent function and it's test to get rid of a bug, which was, that subsequent non-block units where counted to the unit count of the last block