[12.x] allow disabling the use of the "referer" header

[browner12]

this change will allow disabling use of the "referer" header when generating a "previous" URL. to maintain backwards compatibility it is by default enabled.

while the risk is small, headers can be manipulated by things like MITM attacks, so we shouldn't rely on unvalidated user input to control our redirect.

I previously submitted PR #57533 which allows us to enforce the same origin on a redirect. while this is a good addition, as I was writing some documentation for it, I realized it didn't actually go far enough. this only handled explicit calls of building a RedirectResponse, such as with the back() method. However, it failed to address the implicit calls the framework itself makes to the underlying UrlGenerator::previous(), such as the automatic redirection that occurs when ValidationExceptions are thrown. this PR gets to the root of the problem, and provides a way to disable the header use globally.

I'm sure some people reading this will be saying I'm making a mountain out of a molehill, and while I tend to agree the risk is small, I still think it's important to allow the developer to choose here. As I and others have mentioned, this "vulnerability" does often show up in audits. Even though the threat vector is small, and there are possibly a handful of other security best practices that must also be missed/ignored for this to be viable, internal and/or external stakeholders still may want to see this fixed. As a personal anecdote, this "vulnerability" is currently holding up my company from closing a deal with a new customer.

Given the fact that we can also pull a previous URL from the session (something we have more strict control over), I've been racking my brain over the last week of an actual use case of wanting to allow an external URL to hit our application, and then sending the user back to that external URL. I could not come up with any, but maybe they do exist, and would love to hear if anyone has one. This goes more to the question of if we would make any adjustments in v13, but that can be a separate discussion.

I'm not 100% sure how we are handling config values now, so let me know if this change was incorrect.

[vadimonus]

@browner12 , referer is header, and it can be easily manipulated with middleware.
Maybe it's better to create some middleware SanitizeHeaders, wich will remove referrer header at all? If you think it should not be trusted.
In this case you can add middleware to current larave/framework version without breaking backward compatibility, because it would not be used by default.

Then you can add usage of middleware in laravel/laravel. It would affect all new projects, but will not touch any already created projects.

With middleware ou can easily enable it for many new projects, but that used current logic for years can continue upgrading to new version for many more years. In case with config, there allways will be a breaking moment, when you will switch config option