feat: list can be scoped to a single user, to view only their collection

[dustmop]

Now that scope exists, and is created by dispatch, let's allow list to operate on behalf of the user requesting the datasets, so that they only get back their own collection. Until we have proper collections in place, set the active profile and then use the peer option on list.

[dustmop]

Incoming http / rpc requests should have an auth token (created by qri access token --for me) sent as an "Authorization" header. The scope builder in lib/dispatch.go can parse this token in order to get a jwt token which has a subject that is equivalent to the profileID for the user making the request. For nodes that hold references, we then use that profileID to list only the datasets that the asking user owns.

If a list request comes in that does not have an auth value at all, we have two choices on how to handle it:

1. Reject the request, sending back a 403
2. List the dataset references in the collection of the repo owner

The current state of the world is (2), but this won't continue to work for "hosted" qri, such as a remote that multiple users may push to, but that doesn't want to allow these pushed refs to automatically be publicly listed. We might want to always require a auth token, and then change the behavior for a missing token to option (1) as stated above. Alternatively, we could add a configuration option to lib.Instance such as LocalRepoOwner that will default to false but can be assigned during lib construction by the qri core binary. If true, then a missing auth token would continue to be treated as (2).

A related bug we need to fix is that datasets that get pushed to a remote need to have their profile and keypair stored in that remote's profileStore and keyStore. Currently that isn't happening, and those stores are only populated by p2p connections.

[dustmop]

This should nearly basically work right now, but is hard to setup for testing and development purposes. It's not easy to run a qri node such that multiple users can push or save to it. Multiple profiles' data could be hacked into place, but it would be much easier to validate the intended behavior if qri could easily much in "remote mode" like it used to. So, this issue isn't super high priority as cloud's list functionality is entirely separate and doing the right thing, so this is moving to the back burner for now.