clang-tidy: Inconsistent and unenforced use of trailing underscores in struct member vars

Envoy [style guide](https://github.com/envoyproxy/envoy/blob/v1.39.0/STYLE.md#deviations-from-google-c-style-guidelines) dictates that:
```
- Struct/Class member variables have a _ postfix (e.g., int foo_;).
```

In practice the codebase uses both styles. Various examples of

trailing underscores:
- [envoy/thread/thread.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/envoy/thread/thread.h#L58)
- [envoy/server/admin.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/envoy/server/admin.h#L116)
- [source/extensions/filters/http/bandwidth_share/filter_config.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/source/extensions/filters/http/bandwidth_share/filter_config.h#L30)
- [source/common/config/utility.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/source/common/config/utility.h#L58)

no trailing underscores:
- [envoy/tracing/trace_reason.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/envoy/tracing/trace_reason.h#L25)
- [envoy/ssl/handshaker.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/envoy/ssl/handshaker.h#L125)
- [source/extensions/filters/http/mcp_router/backend_stream.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/source/extensions/filters/http/mcp_router/backend_stream.h#L57)
- [source/extensions/filters/http/set_metadata/set_metadata_filter.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/source/extensions/filters/http/set_metadata/set_metadata_filter.h#L28)

and a little bit of both:
- [envoy/http/async_client.h](https://github.com/envoyproxy/envoy/blob/v1.39.0/envoy/http/async_client.h#L437)

The current clang-tidy configuration only enforces this for private member variables [here](https://github.com/envoyproxy/envoy/blob/v1.39.0/.clang-tidy#L96).
Adding rules for `PublicMemberSuffix` and `ProtectedMemberSuffix`, or just `MemberSuffix`, would also cover structs.

To avoid having to rename everything at once in a massive PR, the CI check could be configured to enforce this only for new and modified code. This would allow the inconsistency to phase out naturally over time.

It would still be quite a lot of effort that may be better spent elsewhere. Just throwing it out here as something to think about during a coffee break.

Start with .clang-tidy at the member-suffix configuration and review the linked header examples to understand the existing naming variation. Determine the intended scope for public, protected, or all member variables and how CI would identify new or modified code; done means the chosen rule is enforced without requiring an immediate repository-wide rename.

Written by the indexing model from the issue text.