Joystream Javascript SDK vision

### Intro

I think it's quite clear some sort of Joystream SDK is badly needed. As it is today, to write even simple application on top of Joystream, you need to have solid understanding of a lot of the system characteristic, ways to interact with it, etc. Even integrating with our storage system is troublesome and would be a challenge for a newcomer. If we want people to experiment with Joystream and build new applications, some sort of SDK is a must. Having a set of solid, tested and reusable libraries should make not only development of new applications much easier and welcoming, it can also help by improving our current applications. For example, the storage integration layer in Atlas could be improved in a lot of ways and storage SDK could be a way to do that.

### Proposal

I propose we develop a set of libraries to interact with different pieces of the system. Ones that immediately come to mind, in order of execution, as I imagine:

1. Utilities - set of basic utilities that will be used as building blocks for other libraries. This could include things like, block height<>date conversion, $JOY utilities, utilities for metaprotocol and more.
2. Storage - full integration with the Joystream storage system, allowing to programatically upload an asset, download, etc. Possibly also containing utilities for leads to manage the system.
3. Extrinsics - actual methods for interacting with the Joystream blockchain. It's useful to have TypeScript wrappers over raw RPC methods that can create necessary types/prepare the data. This will probably be the hardest to get right and it's to be seen whether that's a single package.

I propose we use the Polkadot.js naming scheme and use npm package names like `@joystream/utils`, `@joystream/storage` etc. I think all of those should also be kept in a single repository (ideally under `Joystream` GitHub org) as a monorepo, with each package having its own proper versioning. @bedeho will it be possible to give AWG access to Github repo and npm organization? If that's an issue, as an alternative, those could be published under `@joystreamjs` org.

For storage and extrinsics libraries, proper RFC with proposed API will be created in advance so the community can discuss how the libraries should shape up.

I think our ultimate goal should be to integrate those libraries into Pioneer and Atlas, once mature enough. When discussing the libraries, we should keep all the possible Pioneer/Atlas usecases in mind, to make sure our SDKs are robust enough to support our apps.