Tighter integration with datalad credential management

[mih]

At the moment, the special remote expects OSF_TOKEN (or the fallback user/pass) environment variables to be present, as the only way to provide credentials. The test infrastructure, however, already interfaces with DataLad's credential access tooling.

I'd say, if DataLad is found (which in the present setup is pretty much guaranteed), it should also do that in the special remote.

[mih]

Mostly addressed in #95

What is still missing is a small osf-setup command that asks for the credentials, and/or optionally creates a token via the API (if that is possible).

[mih]

It would make sense to me to support a scenario where a dataset itself contains an OSF auth token. This is similar to git-annex's "shared" encryption model. The token could be placed into .datalad/config and we would need to make sure that it is used for a particular dataset. A complication might be that sometimes a user might have dedicated auth configured for their personal account, while an embedded access token gives access to additional projects that their actual OSF has no access to.

Related: datalad/datalad#4135