[Enhancement] Mockit Project Architecture

I have dived into Mockit's code. Overall the idea seems awesome. But I have a few discrepancies to list regarding the project and it's execution:

## Problems

- Docker seems like an overkill for this. We can simple have node scripts run which will do exactly what Docker is doing.
- While development it is a big pain as the client HMR does not work as expected. For it to work effortlessly, one needs to go into the client folder and run `yarn start` or the likes.
- For one to use Mockit, they need to clone the entire repository. This is counter-productive, since I cannot run separate instances of Mockit.
- We can do something similar (though it does not have a UI, but still good to mock) using Glitch (https://glitch.com/). So we do need to determine the scope of this project.

## Solutions

What I propose is, for the project to be meaningful and to be integrated into a proper development workflow, we should do the following:
- Define the scope of the project. Right now it's too cluttered and closely knit with this repository itself.
- Split out the project into client, server and CLI separately.
- Build a better dashboard with more controls.
- Make it into something like CRA, such that multiple instances of Mockit can be deployed.
- Introduce some code formatting guidelines. Right now, the project has no linting. This is difficult as every file, formats as per the contributor's IDE specs.

Additionally, we should create an org on GitHub, under which everything will reside. We could follow a mono-repo structure sans Docker, and use Lerna instead. I believe that will solve a lot of the problems, and help give out more meaningful messages in the console to the contributor during development.

Do let me know what you think!

The issue names Docker, the client folder, yarn start, and a possible Lerna monorepo, but no specific files or tests. Begin by mapping the current Docker and client development setup and clarifying the intended boundaries for the client, server, and CLI. Done requires an agreed scope and implementation plan for the proposed repository and workflow changes.

Written by the indexing model from the issue text.