break up actions.AddDataset into remote and qfs

[b5]

actions.AddDataset makes less sense now that we have the remote package, which wants to take over the duty of pushing & pulling a dataset.

AddDataset currently tries both a dsync pull and a p2p fetch in parallel. The registry fetch already uses a remote client, and In practice this means we're only ever pulling from the registry, because the remote client comes back faster. We should change this up so the remote goes first, and if it fails, we fall back to base.FetchDataset.

Long term, we should remove base.FetchDataset entirely, and just rely on the properties of qfs to perform an IPFS add request on our behalf for data we don't have.

One kinda newish requirement shakes out of this: if the remote package is going to fail, it should fail quickly. If a user runs qri add peer/foo --remote peername, and that peer isn't online, we should be moving to p2p fetching ASAP.

Let's close this first qri-io/dag#26. As the first course of action, dsync now bears the responsibility of knowing when no work needs to be done.