Protocol Jackson improvements

[npepinpe]

Description

There are some existing issues with the current implementation of the protocol-jackson module. The main issues are:

1. For every type created in protocol, we need to add a corresponding type in protocol-jackson.
2. This is error prone (as example, we already have missing types), and it's not so easy to add tests to guarantee this (though do-able)
3. This adds unnecessary overhead for developers
4. The Immutable implementations are hidden - this was to reduce the API surface, but it turns out that this blocks, to some extent, interoperability with other tools and libraries, especially those operating by reflection (e.g. fixture/data generators)
5. Each of the types added in protocol-jackson need to also define how to deserialize nested types. This is also error prone and adds overhead for developers, and difficult to ensure via tests.
6. Copying into an immutable structure is a shallow copy, as Immutables doesn't recognize that, say, JobRecordValue is equivalent to AbstractJobRecordValue.

The proposed solution is:

• Annotate the existing types in the protocol module directly. These annotations are compile-time only, and as such, there is no extra dependency added to the module.
• We combine all required annotations in a single one: ZeebeProtocolValue (or even just ProtocolValue - or suggest anything). This not only makes it easier to guarantee all types are correctly annotated, but also opens up the way for Use annotations to link values, value types, and intents together #8886 and other properties we would like to enforce in our protocol
• We would not add the Jackson bindings there, however, but instead keep protocol-jackson specifically to define a ZeebeProtocolModule, as is common with Jackson to define custom serialization.
• A new module will be created, protocol-util, which would add utilities to help using the protocol, notably make explicit the mapping of ValueType, Intent, and T extends RecordValue, and also keep track of the mapping between the interface types (e.g. JobRecordValue), their immutable counter part (e.g. ImmutableJobRecordValue), and their builders (e.g. ImmutableJobRecordValue.Builder). This is then used by the protocol-jackson module and any other module which wants this information (e.g. protocol-test-util).

This has several advantages:

1. Copying is now a deep copy, as you would expect
2. You can more easily use the Immutable* variants when you need to, and if you don't care about the serialization part, you can still use them
3. We can easily add a ArchUnit test which checks that the interface types are correctly annotated (which guarantees they will generate an immutable equivalent)
4. The mapping of ValueType, Intent, and values is made explicit - this can be further improved via Use annotations to link values, value types, and intents together #8886
5. It makes it very easy to add a random record generator once we have protocol-util and the immutable variants
6. The protocol-jackson module now is better defined - it's literally just a single Jackson module which you add to your object mapper and now knows how to deserialize the Zeebe protocol.
7. Having a random record factory which you can semi control (i.e. reusing protocol-util) makes it much easier to write exporter unit tests, where the data in the records isn't so important in most cases

See the draft PR for an idea of what it would look like.

[npepinpe]

First step would be:

1. Annotate the protocol types directly, but do not use them yet.
2. Introduce protocol-util, use accordingly in protocol-jackson.
3. Refactor protocol-jackson to use the new types, i.e. it now only produces a single ZeebeProtocolModule as its public API. Update anywhere else which was using protocol-jackson.

We could do this in 3 PRs, ideally without too much time in between as otherwise there's dead code floating around which just leads to confusion.