Consider inverting the messages dependency

Currently everything depends on messages.

* This happens partially because messages contains the entire domain.
* And partially because we use messages as the Gherkin AST.

This is not great because:

* We have a serialization format at the core of our domain rather then in an adaptor.
* Because the Gherkin AST is the serialized format we can not utilize any patterns that make working with ASTs easier.
* When anything in the domain changes, everything has to be updated.
* Messages depends on Jackson. Due to it's nature as a de-serialization library [Jackson gets frequent security updates](https://search.maven.org/artifact/com.fasterxml.jackson.core/jackson-databind).

As a visual aid (note note quite accurate, I was sketching out something else):


As such I would propose inverting the dependency and splitting messages into several smaller submodules. The modules are already hinted at by the comments in the proto file.

https://github.com/cucumber/common/blob/f96daddbedd679969bee1609ac9a71e857752720/messages/messages.proto#L13-L43

By inverting the dependency:

* We push the serialization format out to the edges of the architecture. This allows for proper ports and adaptors design. Only root dependents (e.g. the Cucumber CLI) would have a dependency on messages.
* The impact of updating external dependency changes is limited to the root dependents (e.g. the Cucumber CLI).
* Changes that impact Gherkin won't impact execution related code.and vice-versa.


Now I imagine the biggest perceived obstacle will be additional copying the domain objects into messages. However for example if the Gherkin AST was modelled as a tree of nodes using the visitor pattern it would be relatively straightforward to convert it to a message object.