Adds basic auth to REST API

[carsonfarmer]

Also includes username and password handling at the cli. Fixes #894. Note this is an initial implementation, probably not the 'final' version by any means. But let's try it out and discuss. Some details:

• Supports ENV vars for cli tools (TEXTILE_USERNAME AND TEXTILE_PASSWORD) respectively, along with per-command flags --username and --password. I would have preferred to use pin or pincode, but this conflicts with the pin used in textile daemon and textile init, which seem to mask this one?
• Browsers should just automatically provide basic auth support, and by default, should also support 'saving' the password.
• The username is simply the peer's address, and the password is the pincode that was used to encrypt the datastore. If none was used, basic auth is disabled. Simple.
  • This initial implementation makes sense to me because, if we want to support remote 'cafes' with multiple peers, the users should really be providing the pincode to use for encryption...
  • Having said that, the pincode 'borrowing' is more out of convenience than anything 🤷‍♂

Here's how it works from the cli:

$ textile profile
// nothing
$ textile profile --username P7blahblahhash... --password password
{
    "id": "12D3KooW...",
    "address": "P7blahblahhash...",
    "created": "2019-09-06T20:50:27.992900Z",
    "updated": "2019-09-06T20:50:27.992900Z"
}
$ export TEXTILE_USERNAME=P7blahblahhash...
$ textile profile --password password
{
    "id": "12D3KooW...",
    "address": "P7blahblahhash...",
    "created": "2019-09-06T20:50:27.992900Z",
    "updated": "2019-09-06T20:50:27.992900Z"
}
$ textile profile
// nothing
$ export TEXTILE_PASSWORD=password
$ textile profile
{
    "id": "12D3KooW...",
    "address": "P7blahblahhash...",
    "created": "2019-09-06T20:50:27.992900Z",
    "updated": "2019-09-06T20:50:27.992900Z"
}

and here's the gif showing browser support

[carsonfarmer]

With the docs update, the swagger docs actually show each API endpoint is 'locked', and you can 'authorize' at the top. Its a nice UX for testing things out.

[carsonfarmer]

Good idea @sanderpick, added. The 'hacky' (its not that bad) version I added there is needed because the Basic Auth middlewear from gin doesn't add an error message to the response body... so our tooling doesn't pick it up.

[sanderpick]

Sweet!