Clarify dependencies between framework source components

[eddyashton]

The build-time dependency graph between components in CCF has grown messier over time. We originally had README.mds in some src/ folders indicating their intended dependencies, but these have rotted over time.

We should re-evaluate what dependencies we have and can enforce, to keep the code base navigable.

A few high-level goals to start with:

• Public headers should not include any private headers (#2428).
• 3rd party/STL libs are generally useable anywhere/visible everywhere (for instance nlohmann/json is used throughout the codebase, including in core containers), with a few exceptions: We should limit visibility of anything platform-specific (including SGX and host-only libraries).
• ds/ should not depend on anything else. This is a place for generic containers and shims that may be used by multiple other components.
• We should aim to have a set of pure components which depend only on ds/. For instance crypto/, tls/, and http/ could be written like this - generic protocol implementations and helpers, stripped of platform-integration features.
• Where we have tightly-coupled systems like kv/ and consensus/, we should try to document this coupling to ensure it is required.

[eddyashton]

The repo currently contains 3 READMEs which claim the following dependencies:

ds/README.md
# Data Structures

This directory contains data structures and utilities used by the rest of the code. No files
in this directory should include files from any other directory.

kv/README.md
# Transactional Key Value Store

This directory implements a transactional key value store. The only directory
it should depend on is `ds`.

crypto/README.md
# Crypto

This directory implements several cryptography helper types. The only directory
it should depend on is `ds`.

None of these dependencies are currently enforced. The actual dependencies between the folders under src/ look like this:

Dotted lines show mutual/circular dependencies. Initial thoughts:

• We're aware of the mutual dependency between kv/ and consensus/, and believe it's extremely hard to break
• We should try to break the dependency from ds/ to crypto/
• A surprising number of things rely directly on crypto/, I wonder if it's worth splitting this
• This shows we do already have a few 'clean' components at the bottom of the tree, which are only consuming other libraries (clients/, host/, apps/), we should enforce that distinction while we have it