Improve logging around surface creation

[Wumpf]

Connections

• Split out of Fix Vulkan surface capabilities being advertised when its query failed.  #6510
• tiny part of INFO-level logging is too verbose #3206

Description

• demoted a few info messages to debug
• request_adapter is more talkative about its decisions in debug log messages now
• add a doc line to RequestAdapterOptions::compatible_surface, this duplicates what we already write on wgpu's request adapter, but better to request this weirdness where it's needed!

Testing
ran hello_triangle and looked at things

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[nical]

Looks good to me but I remember @jimblandy mentioning a while back that having some of the adapter related logging in firefox (which filters out anything below info and it's tricky to change because reasons) was important.

[teoxoy]

We should probably use the api_log! macro.

[Wumpf]

to be clear, I'd really prefer having those logs in debug :) (telling users to run a program with RUST_LOG=debug is a common thing I do when encountering issues rendering issues)
so api_log would mean I don't have them on trace unless I enable the feature which pushes it to info

[teoxoy]

I see but we still need a way for these to show up at the info level or else they won't show up at all in Firefox.

[jimblandy]

I've had the situation explained to me a bit more now 😅

At Mozilla, we're definitely going to want to understand how adapters got chosen or ignored, when something isn't working as expected. However, Firefox builds remove all logging below info severity; you can't set RUST_LOG to enable it. The key function of wgpu's custom logging macros, for us, is that, when the _log_info features are enabled, they implicitly promote severity to info, so that it's still available in Firefox.

So we would want the adapter creation logging, and we'd want it done in some way or another that allows us to retain it in Firefox.

Beyond that, I don't think we have strong opinions about what the logging should be.

[Wumpf]

Yeah, I also definitely want to have these things in the log, which is why I added more in this PR .. just.. I want them on debug 😄
I have the exact same problem of trying to understand how adapter selection went on user's machine, but for me this is something I let users opt into to get more information out ("thank you for your report, can you please give me the lot output when running RUST_LOG=debug" sort of thing)
Semantically, the information logged here is debug information (imho) - it is information that is generally useful for debugging and it is not as verbose as a full trace. I find it a bit insane to remove all log below INFO and then expect anything for debug logging to be present, but I do have a lot of (unironic) sympathy for big software being hard to be sane like ever.

Anyways, that puts us into an uncomfortable spot though - using api_log puts the information into trace, which is too low to capture it for me (rather than too high where it is right now). Also, it is not quite correct semantically either as the feature is defined as:

## Log all API entry points at info instead of trace level.
api_log_info = []

So what we could do is to stretch the meaning a bit:

## Log all API entry points at info instead of trace level.
## Also, promotes certain debug log calls to info.
api_log_info = []

and then go with that meaning for the calls I demoted here. That way we can have the cake and eat it too without further over-engineering this. Thoughts?

[Wumpf]

the methods that were demoted on wgpu-core are now no longer demoted to debug iff api_log is enabled.
The demoted Vulkan ones are still demoted to debug as the feature isn't available there, but I figure they weren't as contentious to begin with