Unified RESTful API

**Feature description**

Redesign RESTful interface endpoints

**Is your feature request related to a problem? Please describe.**
Current REST API merely wraps the underlying imperative (message-based) structure of hw-go library. HTTP methods , MIME types , and other features are respected though .

**Describe the solution you'd like**
An API more focused on logical resources rather than the underlying procedure that makes it happen .

**Additional context**
Based on [RESTful API design best practices](https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api#http-status) and [HATEOAS](https://en.wikipedia.org/wiki/HATEOAS).

**Possible implementation**

Hereinafter logical resources listed , base URLs included and proposed modifications explained and bound to underlying firmware commands

- **Firmware** operations of device firmware
* `PUT /api/v1/firmware` => `firmwareUpdate`
- **Wallet** a Skycoin (Skyfiber) wallet recovered in SkyWallet device
* `POST /api/v1/wallet/backup` => `backup`
* `PUT /api/v1/wallet/seed` => `recovery`
- `word_count` , `use_passphrase`, `dry_run` as usual only if `seed` not set
- support links for appropriate intermediates e.g. pin code, word, ...
* `POST /api/v1/wallet/seed` => `generateMnemonic` or `setMnemonic`
- `seed` input param , if set , triggers `setMnemonic` else `generateMnemonic`
- **Wallet addresses** list of addresses managed by device
* `GET /api/v1/wallet/addresses` deterministic wallet address sequence
- support pagination args with links for first (if applies), previous and next page only (no last `rel` since sequence is infinite)
- **Features** Wallet features and settings
* `PUT /api/v1/features` => `applySettings`
* `GET /api/v1/features` => `getFeatures`
- Meta operations
* `PUT /api/v1/cancel` => `cancel`
- Intermediates
* `POST /api/v1/intermediate/pin_matrix`
* `POST /api/v1/intermediate/passphrase`
* `POST /api/v1/intermediate/word`
* all instances include single `value` parameter

Other useful features

- [ ] Pagination arguments `page` , `take`
- [ ] Implement [link header](http://tools.ietf.org/html/rfc5988#page-6) for
* resource pagination
* intermediates hints
* operation cancellation
- [ ] Support `JSONP` by also exposing metadata (e.g. for wallet addresses) when either `callback` or `jsonp` params supplied in . Metadata should include, when appropriate:
* `paging` pagination hints , same as included for pages in `Link` header (see above) with `rel` name as object key
* `action` URL of intermediate endpoint needed as call for action e.g. pin matrix
- [ ] Same behavior as above , but without callback name if `envelop=true`
- [ ] HTTP method override via universal `method` input parameter (since some client APIs libraries only support explicit `GET`/`POST`)
- [ ] `409 Conflict` HTTP response if invalid state detected e.g. attempt to recover device already initialized

**Describe alternatives you've considered**
Other sophisticated alternatives are beyond scope. The goal is not to over-complicate the API , but to unify it and include navigation hints.

`setMnamonic` invocation makes more sense via `PUT` request , but overcomplicates endpoint semantics . Therefore was moved to `POST`

Intermediates can be implemented in a single endpoint with `type` and `value` fields

It would be nice to transform `POST /api/v1/wallet/backup` into `GET /api/v1/wallet/seed`, but operation has side-effects