[10.x] Add can middleware helper to resource routes and route registrar, improve consistency

[tontonsb]

I really enjoy the can method added in #39464. So much that I often run into situations where I try to use it but it's not available there (yet).

This PR adds the ability to use of can in these two constructions:

Route::resource('users', UserController::class)->can('manage-users');

Route::can('view-enums')->group(function () {
    Route::get('statuses', fn() => 'Ok');
});

To prevent can('action')->middleware('mw') or middleware('mw')->can('action') from overriding each other I changed the behaviour of ->middleware() to merge the middleware stack instead of overriding it:

Route::middleware('a')
    ->middleware('b')
    ->get('users', fn() => 'Ok');

Route::resource('users', UserController::class)
    ->middleware('a')
    ->middleware('b');

These previously lead to middleware stack ['b'], but now lead to middleware stack ['a', 'b'] and that is why this PR is a breaking change. This new behaviour is consistent with how ->middleware('x') behaves on a route (e.g. when chaining after Route::get()).

And one more consistency improvement is that comma-separated arg list can now be used to set multiple middlewares on resources, just like it was already available on Route::middleware() and Route::get()->middleware():

// Previously 'b' and 'c' would be discarded
Route::resource('users', UserController::class)->middleware('a', 'b', 'c');

[taylorotwell]

I'm really hesitant to change that middleware merging behavior. I could see that really biting us 😬

[tontonsb]

@taylorotwell If I may continue the discussion a tiny bit, is this API inconsistency really intentional/desired?

// Merges middlewares to produce ['a', 'b']
Route::get('ok', fn() => 'ok')->middleware('a')->middleware('b');

// Overrides middlewares producing ['b']
Route::resource('users')->middleware('a')->middleware('b');

Or is the objection only about the merging on registrar? Or just my merge implementation looking fishy? 😂