This is a WIP/RFC attempt at extracting DAGService from go-ipfs.

This way, not *all* DAGServices need to implement this interface, they can just
implement it as an optimization.

Also:

1. Specify the threading guarantees.
2. Vastly simplify it to use a single channel for synchronization.

We'll just live with this name.

We're going to want to do this eventually and we have to refactor anyways so we
might as well do this now.

Fixes ipfs/kubo#4010

This will allow many consumers of `DAGService` to take `NodeGetter` instead and
implementing `GetMany` for all `NodeGetter`s is pretty trivial.

Keep merkledag clean.

It really just doesn't fit. We're working on making this method obsolete
anyways.

(ipfs/kubo#4296)

1. Modern storage devices (i.e., SSDs) tend to be highly parallel.
2. Allows us to read and write at the same time (avoids pausing while flushing).

fixes ipfs/kubo#898 (comment)

1. Add is already idempotent. This makes remove match.
2. Generally, all we care about is that the node no longer exists in the DAG. If
two callers remove a node at the same time, they should both succeed. Currently,
we *ignore* the result of Remove in go-ipfs. IMO, it would be better to let
errors be *errors* and only return an error if something goes wrong.
3. This can be significantly faster. It allows us to batch/queue removes (as
long as we guarantee that they'll eventually happen).
4. This matches how most databases/key-value stores operate.

An alternative would be to return `(deleted bool, err error)` but then we don't
get the speedup.

The caller can just call `node.Cid()` and returning CIDs from `AddMany` requires
allocation.

We'll need these for slower/remote datastores.

I considered (well, implemented then threw it away) allowing contexts on all
calls to Batch (Add, Commit, etc). However, really, you should treat a batch
as a single large "operation".

I also went down the road of generalizing batches to sessions. However, it
became immediately obvious that permitting add *and* remove *and* fetch would
require a lot of bookkeeping and that you'd lose a lot of performance. So, we'll
do that separately.