Consider United Messaging Model

Nobody has claimed this yet.

Currently, Jakarta Messaging has its own text and binary message definition, and WebSocket supports InputStream, String, StringReader, etc. We can get the inspiration from Spring framework, Spring Integration, etc to unite the messaging model.

Use headers/body or properties/payload to describe a message at runtime.

```java
record Message(Map headers, T body){}
```

With the message conversion #1023 support, in Jakarta Messaging and WebSocket, we can use a simple type-safe approach to get the message payload directly.

Jakarta Messaging and WebSocket can adapt the Message to simplify the development for developers. In WebSocket lifecycle hook methods or Jakarta messaging listener methods, it can accept the message headers and payload as parameters directly.

```java
public void onMessage(
@Headers Map headers,
@Payload MyObject payload
)

public void onMessage(Message message)

public void onMessage(MyObject payload) // none `Message` type, it is a payload directly

```

And `headers` and `payload` should be available in the Jakarta Messaging Lisneter `selector` EL as described in https://github.com/jakartaee/messaging/issues/243#issuecomment-2569877617

Start by reading the proposed model in this issue, the message-conversion work in #1023, and the referenced Jakarta Messaging discussion. Determine the specification changes needed for Jakarta Messaging and WebSocket adaptation, listener parameters, and selector EL access; done requires an agreed unified model and defined behavior across those APIs.

Written by the indexing model from the issue text.