Fixes #3447 and #3446.

This adds a number of features and improves Google authentication.

• Project ID is no longer always provided by the credentials provider. It's now an Option, which means credentials provider that are not able to provide a project ID can be implemented. The API that has been changed was internal so nothing has broken here.
• A new project-id parameter has been introduced at the top level of the Alpakka Google configuration. Rather than just loading the project id from the credentials, this is now read first, and takes precedence. If not provided, then we use the optional project id from the credentials provider, and if that's not provided, we then use another new configuration parameter called default-project-id, which is configured to read the project id from environment variables, eg GCP_PROJECT or GOOGLE_CLOUD_PROJECT. In many environments, eg when workload identity is being used, these environment variables may be automatically set. This is actually an important feature, because the project id from the credentials provider is tied to which project your principal is in, but there's no reason why that project must be the same project that you want to access. Google principals are global, you can grant a service account in one project access to GCP in another, for example.
• The application-default credentials provider has been reworked, and is now more robust. Instead of each provider being responsible for loading the file itself, and this selecting one based on which one didn't fail to load, the type field of the application JSON file is read, to decide what type of credentials to read. So, a new path parameter has been added for what to use when application-default is configured. Failure to configure from the JSON file results in attempting to load GCE credentials.
• A new credentials provider has been added, external account. This allows federated workload identity to work, for example, in GitHub actions. So far it has only been tested with GitHub actions.
• Credential providers can now be closed, with a new close() public API method being added. This means that when dynamically loading credentials, resources, such as the actors running the caching stream for OAuth2 credentials, can be cleaned up when the credentials are no longer needed.
• A new custom OAuth2 credentials class has been created, allowing custom access token loading strategies, which is useful on platforms where an access token is provided in an environment variable via workload identity, or so that users can implement their own authentication providers, which is a necessary escape hatch since there's several other Google application JSON credentials types that we still don't support.

I've been careful to ensure that this is backwards compatible, there's no binary breakages, but the following scenarios may break:

• If someone is relying on the application-default provider, but they have placed configuration in one of the other providers, the old application-default provider would read that config. Now it doesn't. For example, if you configure a service account using the config keys, rather than using an application json file, and you don't set provider = service-account, that used to work, but it doesn't now. The solution is to be specific about which provider you want to use.
• If someone has generated their own application json file without the type parameter, this will break the application-default provider. This parameter is considered compulsory by the Google SDK.