Convert RulesUI to work based on RulesComponent

plan:
- somehow add RulesComponent to request attributes
- convert Forms to have RulesComponent as controller argument instead of the config. This will let the controller resolver pick up the component from the attributes and pass it to the form
- then, of course, convert the forms to work without the config

Question is how we can add the component to request attributes best. one variant would be extending the HtmlFormController to override FormController::getContentResult(). Then, we have to specify our own controller in the _controller key of the routes. The proper way seems to be to use route enhancers though, looks like FieldUiRouteEnhancer is good a example doing something similar: it adds a 'bundle' parameter.

Finally, this is ready to review (only one test-fail left which I'm fixing atm).

Unfortunately, there was quite some refactoring necessary. I had to re-factor the whole logic around the tempstore also. Here is a summary:
- rules_ui plugins come with a handler and a default implement for components stored to config. via custom handlers it will be possible to store stuff elsewhere also, e.g. conditions in content entities
- handler classes can be defined in the rules_ui yml and come with with a per-handler settings array to define handler specific stuff also
- in the generic ui settings, there is the reference on the base-route. below this route all expression routes are generated
- the routes are marked with _rules_ui, which is picked up the route enhancer. the route enhancer adds in the rules_ui_handler route parameter, which is the handler of the currently active UI
- the handler takes care of the temp store logic and provides getComponent() and updateComponent() methods, which the forms in turn use for editing
- I had to refactor expression form logic quite a bit to work based upon the component. while doing that I made AddExpressionForm extend EditExpressionForm as this allowed me to easily re-use most of the logic. It now follows entity form workflows for validation; i.e. it has buildComponent() that builds an updated comonent based upon the form values.
- AddExpressionForm was fixed such that a validated expression form is attached to a component. This caused me a bit of a headache to get right, but works now. However, this is critical form expression integrity checks to perform right as they need to have access to the available context at their execution position.
- We might want to overhaul the ExpressionFormInterface to be streamlined with the form methods in the configurable event handler, as right now submitForm() is called for value extraction before validateForm() even what's totally confusing. once renamed the workflow should be clear.

I fixed the last fails, but:

i looks like the changes fail on PHP > 5.5, while it's working on 5.5. I've still 5.5 running, so I've to setup a different env here first for being able to fix that :/

Setting for needs review anyway as the changes are ready to review else.

After setting up PHP7, I was able to reproduce this. Not sure why this does not happen with 5.5, but the cause is: #2669032: Form objects cannot rely on object properties initialized via route parameters. I added a workaround based on form storage to the code. It's not nice, but we should be able to remove it once we figured out on how to deal with #2669032: Form objects cannot rely on object properties initialized via route parameters later on.

ok, still we've got a problem on php 5.6 left :/

/home/travis/build.sh: line 45: 2816 Segmentation fault (core dumped) php -S localhost:8888

I tried to reproduce this locally, but there everything works fine + tests are green. Maybe it's also the PHP webserver which dies, who knows. I've tested with PHP 5.6.18, travis seems to be running 5.6.6 - so there might be the difference also.

I've already spent way too much time on the PHP compat issues, so I'm going to mark php 5.6 as may fail for now. To resolve, we could migrate the travisci.yml to a docker based webserver setup, what seems more reasonable to me as problems can be debugged and reproduced locally.