Inconsistent behavior between GOOGLE_CLOUD_PROJECT and ProjectIdOption

[coryan]

We have at least 2 ways to send the project id in the storage library. The GOOGLE_CLOUD_PROJECT environment variable, the ProjectIdOption that can be used with google::cloud::Options. It seems that some functions only use one and not the other. And some functions consume a project_id parameter for extra fun.

We need to make this consistent. Application developers should not need to guess which one applies. Keep in mind the option precedence hierarchy.

We have at least 2 ways to send the project id in the storage library.

Make that 3. For HMAC keys we also have OverrideDefaultProject. Sigh.

The story of how we got here is hilarious, but does not fix anything.

---

This issue is from https://stackoverflow.com/questions/76345053/how-to-set-the-project-id-for-c-storage-client

User ADC: If the environment variable GOOGLE_CLOUD_PROJECT is set, the CreateV4SignedUrl works without specifying the SigningAccount parameter. If the environment variable is not set, then the SigningAccount parameter is required.

However, the Project ID should be able to be set via the gcs::Client() option gcs::ProjectIdOption>(project_id), but that seems to be implemented but never processed later in the code.

Originally posted by @jhanley-com in #11740 (comment)