How should go-nitro be packaged for consuming applications?

[NiloCK]

The current go-nitro module exposes a large public API, including:

• funding / defunding protocols
• nitro's cryptography wrappers
• (multiple) channel abstractions
• channel state & outcome data structures
• abi encoding utilities for the above data structures
• ... and the go-nitro client

In draft pr #649, I threw everything other than the client into the ./internal folder, which has the effects of:

1. prohibiting other modules from importing those packages
2. removing those packages from the top-level documentation of go-nitro

@geoknee pointed out that effect 1 is negative. If we want eyeballs & potential contributors to the protocol internals then they should be exposed.

2 is probably a positive, as it makes for a very digestible godoc page for the client itself, which (will) contain all of the API for integrating go-nitro with any other application. IE, just the things that an adopter needs to know about: this module permits the setup & teardown of virtual channels, which themselves permit low-cost high-frequency balance updates to a private ledger between clients.

An alternative approach is for the client package and its children (engine, store, messageservice) to be split into their own module which depends on go-nitro.

Noteworthy: this is a marketing decision as much as a technical one. The first bite is taken with the 👀...