docs: messaging architecture

[hairyhum]

Adding architecture docs to describe messaging properties and building blocks

Checks

• All commits in this Pull Request are signed.
• All commits in this Pull Request follow the Ockam commit message convention.
• I accept the Ockam Community Code of Conduct.
• I have accepted the Ockam Contributor Licence Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the ockam-network/contributors repository.

[dvermd]

This a great piece of architecture

[dvermd]

As Backtracing is not always allowed by the forwarder on the routes from A to B, there may not be a return path by these hops but it doesn't mean B cannot reach A by another route that must be known before-head.
Routes could be A->Fr1; Fr1->Fst2; Fst2->B and `B->Fst3->Fr1->A'

[hairyhum]

Yes. Backtracing is enough to make workers mutually accessible, but it's not required.
Even more, with some state on both ends you can configure forwarding workers to create backtracing routes even if routes in the middle are not backtracing.
For example our Stream channel implementations: messages in the stream are not tracing return route, but add the "reply stream" metadata to the messages.

[dvermd]

You may quote or use any other artifact to visually group the delivery types

Suggested change

	To provide at-least once delivery between workers which don't have additional logic,
	To provide `at-least once` delivery between workers which don't have additional logic,

[hairyhum]

For consistency will use at-least-once, at-most-once and exactly-once without quoting.

[hairyhum]

@dvermd Thanks for review.

[mrinalwadhwa]

Looks great, let's merge these 👍