[1.x] Ensures route password.confirm is defined when not using views

[Frozire]

This fixes #367

If you implement fortify without views, you have to hardcode the password.confirm route because no name is defined on the post route.

fortify/routes/routes.php

Lines 120 to 121 in b2de125

	Route::post('/user/confirm-password', [ConfirmablePasswordController::class, 'store'])
	->middleware([config('fortify.auth_middleware', 'auth').':'.config('fortify.guard')]);

If you have views enabled ($enableViews = true), you are saved because a get route is defined with the same route.

fortify/routes/routes.php

Lines 110 to 114 in b2de125

	if ($enableViews) {
	Route::get('/user/confirm-password', [ConfirmablePasswordController::class, 'show'])
	->middleware([config('fortify.auth_middleware', 'auth').':'.config('fortify.guard')])
	->name('password.confirm');
	}

Currently, this forces people using Fortify with a SPA/custom views ($enableViews = false), to hardcode the password.confirm route.

While this might not be the prettiest fix, it is a fix that will not cause breaking changes for those already using the package.

[driesvints]

Another easier solution is to just name the post route and remove it from the get route.

[Frozire]

Another easier solution is to just name the post route and remove it from the get route.

I've changed this PR according to your suggestions.

[bessone]

with this modification I get an error with the Laravel Breadcrumbs project (https://github.com/diglactic/laravel-breadcrumbs), all the routes in GET must have a name to be used with the breadcrumbs, having moved the name from GET to POST there is no more way to make it work.

PR to correct use without views has created the problem for those who use views (with breadcrumbs)