[Rust] Add ZerobusSdkBuilder::application_name for x-zerobus-sdk header

[flaviofcruz]

Summary

• Adds ZerobusSdkBuilder::application_name(...) so callers can append a custom identifier to the x-zerobus-sdk gRPC metadata header (e.g. zerobus-sdk-rs/1.3.0 my-app/1.0). The SDK version
  prefix is preserved so server-side telemetry still sees the SDK version.
• Moves x-zerobus-sdk injection from OAuthHeadersProvider to the gRPC layer. The SDK now owns this header on both the proto stream and Arrow Flight paths; any x-zerobus-sdk value returned by
  a custom HeadersProvider is ignored.
• OAuthHeadersProvider::get_headers no longer sets x-zerobus-sdk (now redundant). DEFAULT_X_ZEROBUS_SDK remains exported.

The intent is to set the application name in the vector zerobus sink so we know how much traffic is from vector.

Motivation

Embedders (e.g. Vector) want to identify their application in server-side telemetry without having to implement a custom HeadersProvider solely to set one header. Making this a first-class
builder option also guarantees the SDK version prefix can't be accidentally dropped by a buggy custom provider.

Behavior change

Custom HeadersProvider implementations that previously set their own x-zerobus-sdk value will now have that value silently overridden by the SDK-owned one. Use .application_name(...) to
customize. Noted in NEXT_CHANGELOG.md.

Test plan

• cargo test --release — all 107 unit + 80 arrow + integration tests pass
• cargo clippy --release --all-targets clean (only pre-existing warnings)
• New unit tests cover default, custom, and empty-string application_name cases
• Follow-up: add mock-server integration tests asserting the header lands on the wire (proto + Arrow paths) and that provider-supplied values are overridden. Current tests verify
  composition logic but not wire behavior.
• Manual smoke against a real Zerobus endpoint to confirm server-side telemetry receives the expected value

Two notes:

• I left the wire-level test as an unchecked follow-up rather than claiming coverage we don't have — flag it for yourself or me to address before merge.
• If you'd rather not advertise the behavior change to custom-provider users in the PR body (it's already in the changelog), drop the "Behavior change" section.

[teodordelibasic-db]

Hey, we have this on our roadmap, but we will be using the user agent header instead of the x-zerobus-sdk header since we will move to a newer tonic version which doesn't override this standard header. We'll also need to modify server side handling for this and we have a couple of asks regarding it from PM side so I need to see about it first. I'll review this on Monday.