Clarify semantics of negotiationId in ContractRequestMessage

[jimmarino]

A ContractRequestMessage can initiate a negotiation or send a consumer counteroffer to the provider. Since these messages must be idempotent to support reliability, we need a way for the provider to perform unambiguous deduplication:

1. The consumer sends a ContractRequestMessage to the provider, which receives it
2. The provider creates a state machine, transitions it to CONSUMER_REQUESTED, and sends an ACK to the consumer
3. The consumer crashes before it can commit the ACK
4. The consumer recovers and sends the same ContractRequestMessage

At this point, the provider needs to determine that the message is a duplicate and not an attempt by the provider to send a counteroffer, which would result in an illegal state transition. The converse of this is when a provider must determine that a message is a counteroffer, not an initial request.

The proposed solution is the presence of the negotiationId message. If the property is present in the message, the provider should process it as a counteroffer; otherwise, it should process the message as an initial request.