Refactor ui: More saga, less logic in action creators

[marcelklehr]

• [x] Use redux-saga
• [x] expose action types in providers and/or make them simple to deduce (e.g. settings/setForUser instead of SETTINGS_SET_FOR_USER)
• [x] Fix exposure of render functions, replacing them doesn't work atm

[marcelklehr]

Template for action types: category component/[object.]action e.g. trigger:submission chat/message.send

categories of actions:

• trigger -- user does something
  • trigger:response
  • trigger:submission
  • trigger:abort
• evoke -- app does something
  • evoke:prompt
  • evoke:progress
  • evoke:failure
  • evoke:success

When the user clicks on something, this will emit a trigger action. Sagas listen for triggers and emit effects, among which are evoke actions. These can in turn be listened on by other sagas, but, since reducers will typically only act on evocations, they usually produce a change in the UIs.

[marcelklehr]

Saga code should have as little to do with actions as possible. Actions should only be used to update state or signal events, not for invocations. Instead of putting failures, throw an error!