Roll back the kernel/most of routing

Problem/Motivation

Drupal 8 is not releasable and won't be any time soon. The routing system insists on storing routing names/parameters when users enter paths and want to see paths. The necessary conversion back and forth gives us plenty of opportunities for bugs and they indeed flourish (install Drupal in a subdirectory, add a link item, edit and try to save). The page flow is #2327277: [Meta] Page rendering meta discussion simply unfixable within a reasonable time frame. The entity subscribers are the exact opposite of what hooks are (implicit vs explicit, priorities vs weights) yet they are for the same purpose.

Proposed resolution

We had a system once that worked. Adding a few more criteria (HTTP method, Accept header, Content-Type header) to the D7 based routing table (which exists in D8 too) besides the current path would allow for REST without the extra baggage of I do not know how many lines of code.

http://cgit.drupalcode.org/sandbox-chx-1857558/tree/index2.php?h=kernelless
http://cgit.drupalcode.org/sandbox-chx-1857558/tree/core/lib/Drupal/Core... (this is inside rebuild, this is where the fun part is)

Design goals:

• hooks instead of event subscribers
• http kernel is out. The DrupalKernel no longer has anything to do with it.
• symfony cmf routing is out. The only thing we use is the Route value object from Symfony. It's wired too deeply to remove. Copying it into the Drupal namespace, however is feasible.
• what must be called and in a particular order is just called directly. Example: on router rebuild, AccessRouteSubscriber has a priority of -1000 and a comment hoping that fires after everything else. Sigh. We just fire it after calling the relevant alter hook.
• paramconverters die instead we put the load information on rebuild into the parameters and call them directly.
• a little less flexibility: the "page callback" can return a render array or a Response object and that's it. No more "hey return something a view subscriber will deal with it" silliness. This immediately resolves #2327277: [Meta] Page rendering meta discussion . That issue simply ceases to exist.
• a little less flexibility: besides path, we will add method (GET, PUT etc), Accept (or perhaps the format Http Foundation mutates the Accept header into -- so json, hal_json etc), Content-Type (for POST) into the {router} table and then you can select on these four and that's about it. Still does REST but it's 1 quick SQL query returning the route to be used immediately. If you want to put two routes that only differ on X-My-Super-Header then put that into your "page controller". We do not cater to cover the universe. We cater to get maintainable and releasable code. Side note: https://www.drupal.org/node/2058845#comment-8454165 is invalid because it only takes path as a PK into consideration but D8 has far more routes.

After just a few hours, plain pages and entity pages kinda sorta work. _form is close. This is very doable. The amount of code to be removed is gigantic. I am sure there would be quite some performance wins from not executing all paramconverters when they are not needed and other code.

Remaining tasks

Agree. Code. Release. Party.

User interface changes

API changes

Uh oh :)