Add configuration option to require explicit authentication method specification

### Search before reporting

- [x] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.

### Motivation

Currently, when a client connects to a Pulsar broker without specifying an authentication method (via the X-Pulsar-Auth-Method-Name header in HTTP or the auth method field in the Pulsar protocol), the broker attempts to authenticate using all configured authentication providers sequentially until one succeeds or all fail.

While this fallback behaviour provides flexibility, it can create security concerns in deployments where operators want to enforce that clients must explicitly specify which authentication method they're using. This explicit requirement helps prevent:
1. Unintended authentication against the wrong provider
2. Ambiguity about which authentication mechanism was actually used
3. Potential security issues where fallback behaviour differs from operator expectations

### Solution

Add a new broker configuration option `strictAuthMethod` (default: `false`) that, when enabled, requires clients to explicitly specify their authentication method. When enabled:
- Authentication requests without an explicit method will immediately fail with an "Authentication method missing" error
- Clients must specify which authentication provider they intend to use
- No fallback to trying multiple providers will occur

This provides operators with better control over authentication behaviour in security-sensitive deployments while maintaining backward compatibility through the default false value.

### Alternatives

No, this is an additive feature that doesn't change existing behaviour when disabled.

### Anything else?

_No response_

### Are you willing to submit a PR?

- [x] I'm willing to submit a PR!

Begin with the broker authentication handling for HTTP's X-Pulsar-Auth-Method-Name header and the Pulsar protocol auth-method field. Verify the new strictAuthMethod default and missing-method failure in both request paths; done means explicit methods are required only when enabled and existing fallback remains when disabled.

Written by the indexing model from the issue text.