Dedicate some part of the Build Event Protocol to extensions

### Description of the feature request:

Add some safe way of making non-upstream extensions of the Build Event Protocol, e.g. by adding protobuf.Any fields to the `BuildEvent` and `BuildEventId` messages.

### Which category does this issue belong to?

_No response_

### What underlying problem are you trying to solve with this feature?

We have a fork of Bazel that produces data that we want to collect via the Build Event Protocol. This data comes from custom features that are not present upstream, so the changes to the BEP cannot reasonably be pushed upstream. However, we still want to be able to continue to uplift our fork to the latest Bazel version.

If we were to arbitrarily add new fields to the BEP protobuffer definition, there's a risk that the field numbers of these fields would collide with new upstream fields. These collisions would require us to either change the number of our own field, which would make older versions of our fork incompatible, or change the number of the new upstream field, which would make it incompatible with any third-party consumers of the BEP.

One way of working around this issue would be to pick large numbers for extension fields and hope that they are never used upstream. While this would most likely work for sufficiently large numbers, we think it's preferable to have an approach that is guaranteed to work.

We think it would be good to dedicate some part of the BEP protobuffer definition to extensions of the protocol. One way of doing this might be to add new fields with the protobuf.Any type in the `payload` of `BuildEvent` and the `id` of `BuildEventId`. This should allow us to use the BEP to send custom events with arbitrary multiplicity.

### Which operating system are you running Bazel on?

_No response_

### What is the output of `bazel info release`?

_No response_

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_