Split ContractNegotiationEventMessage

[ndr-brt]

In the contract negotiation specs there's a message that's used for two different scopes:

ids-specification/negotiation/contract.negotiation.protocol.md

Lines 151 to 179 in 3f9fc7c

	### 5. ContractNegotiationEventMessage
	
	**Sent by**: Provider or Consumer
	**Resulting State**: PROVIDER_FINALIZED, CONSUMER_AGREED, TERMINATED
	**Example**: [ContractNegotiationEventMessage](./message/contract-negotiation-event-message.json)
	**Response**: OK or ERROR
	**Schema**: [ContractNegotiationEventMessageShape](./message/shape/contract-negotiation-event-message-shape.ttl) and the [ContractNegotiationEventMessage JSON Schema](./message/schema/contract-negotiation-event-message-schema.json)
	#### Description
	When the `ContractNegotiationEventMessage` is sent by a provider with an `eventType` property set to `FINALIZED`, a contract agreement has been finalized and the associated asset
	is accessible. The state machine is transitioned to the `PROVIDER_FINALIZED` state. Other event types may be defined in the future. A consumer responds with an error if the signature
	can't be validated or is incorrect.
	It is an error for a consumer to send a `ContractNegotiationEventMessage` with an eventType `finalized` to the provider.
	When the `ContractNegotiationEventMessage` is sent by a consumer with an `eventType` set to `ACCEPTED`, the state machine is placed in the `CONSUMER_AGREED` state.
	It is an error for a provider to send a `ContractNegotiationEventMessage` with an eventType `ACCEPTED` to the consumer.
	Note that contract events are not intended for propagation of agreement state after a contract negotiation has entered a terminal state. It is considered an error for a consumer or
	provider to send a contract negotiation event after the negotiation state machine has entered a terminal state.

Why not splitting it into two more self-explaining messages like:
ControlNegotiationFinalizeMessage (sent by the provider to the consumer)
ControlNegotiationAcceptMessage (sent by the consumer to the provider)

[ndr-brt]

More than a "split" this was a proposal to have two different messages with the specific eventType set, this would avoid misunderstandings and make the specification cleaner. They would keep the same schema so no duplication needed.