Refactor Route Resolving and Dispatch

[askvortsov1]

Prep for #2170

Changes proposed in this pull request:

• Split DispatchRoute into middleware to figure out which route should be used, and another for actually executing it, so that we can use the route name in middleware in between
• Similarly, logic in RouteCollection has been changed to return the route name as well as the handler function
• CSRF extender has been changed to use the route name instead of path (path still works, but has been deprecated)

Reviewers should focus on:

• Currently, if a CSRF-invalid request is made to a path that doesn't exist, CSRF will be evaluated before the route, so it'll be returned as a CSRF error. Now, it'll return a 404 before getting to the CSRF middleware. When we get to floodgate, this will similarly be an issue: not found will run before floodgate is. I don't think this is particularly problematic, but still something to think about.

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).

[clarkwinkelmann]

Doesn't the order of the middlewares cause the "not found" / "invalid method" error pages to not be translated into the user-selected language? Since SetLocale runs after ResolveRoute. I understand an exception from ResolveRoute will skip the next middlewares which would normally have been executed all the way down to ExecuteRoute.

[askvortsov1]

Ah didn't think of that case, pushed a fix. RequireAdministrativeAbility and ShareErrorsFromSession should be fine after route resolver, I think?

[clarkwinkelmann]

@askvortsov1 RequireAdministrativeAbility and ShareErrorsFromSession should be fine after route resolver, I think?

I think this should be fine the way it is, but haven't done any test on this PR.