Alter terminology to cover solo-solo, solo-chain model

[cwgoes]

Dean Tribble:

Mark observed that we do have an additional purpose for IBC that we think is important and fits technically with the architecture: we always think in terms of communication between machines, where chains are just machines built from agreement. The protocols between relays and chains pretty much include everything required for solo machines talking to chains, and it shouldn't take much to also support solo-solo communication. You can loosely think of a single machine as a degenerate chain, but there might be some plausible terminology that could make it more clear how it maps to those use cases.

I don't think this requires alterations of semantics insomuch as clearer terminology (e.g. "ledger").

Requires a clearer discussion of data availability:

• Get rid of "public" / "private", discuss instead what data is available to who when
• Relayer could be carrier pigeon (relayer still “untrusted’, but enabled by giving the paper to the carrier pigeon)
• Relayer constrained by data availability & anti-spam on receiving chain, liveness dependent on at least 1 correct relayer satisfying both

[cwgoes]

I am going to rename ICS 2 to "Validity Predicate", that's more method-agnostic.

[cwgoes]

Closing in favor of #161 (remainder).