by giving systemAnnouncement a starting value

The old one was result of experimentation. The backend address should be 
/api so it works out of the box.

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

closes https://github.com/iqb-berlin/testcenter-frontend/issues/282

The mock is nw the default, the old dev file was of no use outside the 
setup project, so it is kept there now.

The backend address in the environment file needs to either be localhost 
for using the app from the (host system's) browser of the internal 
docker name (backend-mock) so the frontend container can reach it. SO 
the testcenterUrl can either be reached from the host or fromt he 
frontend container but not both. This makes it so, that the e2e tests 
use a specific environment (defined in angular.json) which uses a 
different environment file for running e2e test within the frontend 
container.

instad the internal one

restores the version of notifyDyingTest with employs the specialized endpoint and the fetch-api als alternative to sendBeacon. It was appareantly lost my merging with master.

No Changes in the behaviour.

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.