[Epic] API is the Product

# Context 💭

As a person who uses Apps/Services, I _hate_ it when my data is locked up in a ["walled garden"](https://en.wikipedia.org/wiki/Closed_platform).

A service might initially solve a problem for me but I have no control over my data, so when it goes bad (_e.g. because the megalomaniac [sociopath](https://github.com/dwyl/learn-react/issues/23#issuecomment-458856362) founder wants [**all** your personal data](https://github.com/evancz/guide.elm-lang.org/blame/1a9369301cdd675c71c1dc01f78eb84875e9f195/book/error_handling/maybe.md#L60) so they can sell you to ads even though there were no ads when you joined in 2007 to stay in touch with friends ..._),
I _cannot_ leave the platform without losing all (_or most_) of my data!
Sure they might provide an API but it's _always_ limited in scope to what they _want_ you to have.

We want to _always_ ensure that **_all_ actions** that can be **performed in** the **Web UI** can also be done via **REST API** and **_all_ real-time notifications/updates** can be subscribed to via **WebSocket API**¹.
That way anyone _using_ our App can _always_ access _all_ of their data and they are not [locked-in](https://en.wikipedia.org/wiki/Vendor_lock-in) to using our service(s).

This is in keeping with our Manifesto: [manifesto.md#your-data-is-yours](https://github.com/dwyl/start-here/blob/master/manifesto.md#your-data-is-yours)

# Story 💡

As a person storing lots of important data in the @dwyl App,
I want to be able to access _all_ of my data at any time via an API
So that I can extract, analyse, update or export my data if I chose to.

As people _using_ the @dwyl App ourselves this is what we would _expect_ from a ~~good~~ _great_ App. Ideally we want to have the API from day 1 (MVP) so that people can _immediately_ access and _create_ their data programmatically.

# Todo

+ [ ] Define the scope of the API (_"everything" isn't a scope!_)
+ [ ] How will we document our API
+ [ ] Will we conform to a particular API Spec e.g: JSON Schema https://github.com/dwyl/learn-json-schema/issues/1
***or*** are we better off just following the good examples that _don't_ conform to a Spec?
see: https://github.com/dwyl/learn-api-design/issues/39 either way I think it's worth updating our knowledge of APIs https://github.com/dwyl/learn-api-design _before_ embarking on building our API.
+ [x] Explore Content Negotiation as a way to keep the App and API as the _same_ Phoenix App.
+ [x] Tutorial to Consolidate our Understanding: https://github.com/dwyl/phoenix-content-negotiation-tutorial/issues/1
+ [x] [SPIKE] Create Content Negotiation Plug: https://github.com/dwyl/content_negotiation_plug/issues/1
+ [x] _Publish_ `content` Plug to Hex.pm: https://hex.pm/packages/content

¹ As noted in our "Why Elixir" thread: https://github.com/dwyl/learn-elixir/issues/102 one of our key reasons for selecting Elixir/Phoenix for our backend tech is for Channels which we feel is one of the "super powers" of the language/framework! Having a scalable Realtime API with presence is one of the key features we need to have for teamwork.