Do not overwrite the Authorization header

## Summary

If the Authorization header has been explicitly set by the user, `requests` should not try to overwrite the header with credentials in `.netrc`.

Anecdotally, I was confused for a solid half hour, wondering why any token I passed yielded the same user before I made an unauthenticated call, dumped headers, and suspected `.netrc`.

See [principle of least surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment).

## Changes

- Updated the authentication conditional in `prepare_request` to check whether the Authorization header (case-insensitive per [RFC9110#5.1](https://datatracker.ietf.org/doc/html/rfc9110#section-5.1)) is set.
- [Bonus] Added a period at the end of the sentence in a nearby comment.

## Related Issues

- Closes https://github.com/psf/requests/issues/3929

If you're specifying headers yourself manually, you should always set trust_env to False for those requests (assuming you want to trust it otherwise). We already have mechanisms to avoid this but certain headers we document our right to muck with, and Authorization is one of them. We will outright remove it in certain circumstances which are also documented. 

One should only use `trust_env` for its intended purpose. To set `trust_env` to `False` as a means of avoiding overriding user-set Authorization will introduce unintended consequences as `trust_env` controls more than just headers. 

Consider the following excerpt from `merge_environment_settings(...)` in `sessions.py`.

```python
# Gather clues from the surrounding environment.
if self.trust_env:
    # Set environment's proxies.
    no_proxy = proxies.get("no_proxy") if proxies is not None else None
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
    for k, v in env_proxies.items():
        proxies.setdefault(k, v)

    # Look for requests environment configuration
    # and be compatible with cURL.
    if verify is True or verify is None:
        verify = (
            os.environ.get("REQUESTS_CA_BUNDLE")
            or os.environ.get("CURL_CA_BUNDLE")
            or verify
        )
```

It is not uncommon for the user to set the Authorization header _and_ use proxy and/or certificate settings from the user's environment. This workaround may be acceptable in some cases and will work for some users, but I would not agree that it is an excellent design choice.

As for circumstances in which the Authorization header is mucked around by the module, I do see the Authorization header is sometimes stripped when resolving redirects to avoid leaking credentials and I agree that this is very useful. The proposed changes will not inhibit this security measure.

I know full well what other settings trust_env controls. Our advice has consistently been to disable that to disable netrc being picked up.

As I said, the way to achieve what you want today is to write an auth adapter to provide the value you want as the header if you're unwilling to accept best current practices for specifying that header directly.

Our reservation of the right to always mess with certain headers isn't conditional. The are many behaviours that are affected by the environment in ways we don't think are optimal anymore but we have a strict backwards compatibility policy which this change and others like it violate 

I find it strange to advise on the basis of "this is what we always tell people" instead of collaborating with the community in an effort to introduce improvements that benefit all users. I thought that was the entire point of open source.

In any case, you're the maintainer, you have final say, and you've closed the PR. The point is taken. Thanks anyways!

> I know full well what other settings trust_env controls. Our advice has consistently been to disable that to disable netrc being picked up.
> 
> As I said, the way to achieve what you want today is to write an auth adapter to provide the value you want as the header if you're unwilling to accept best current practices for specifying that header directly.
> 
> Our reservation of the right to always mess with certain headers isn't conditional. The are many behaviours that are affected by the environment in ways we don't think are optimal anymore but we have a strict backwards compatibility policy which this change and others like it violate

If "strict backwards compatibility" means not fixing behavior the community deems broken, perhaps your policy is broken.