Optionally run Django and Next.js backends outside Docker Compose in development for better performance

#357 brought back a single `docker compose up` command for setting up the development environment from scratch. However, on a 2020 Macbook Pro M1, page compilation is somewhat slower on Next.js inside Docker than it is running `npm run dev` natively.

While we should keep supporting the single command `docker compose up` for setting up the development environment to keep the barrier of entry as low as possible, as a power user option it might be a good idea to give an alternative, equally easy way of starting the development environment so that the Django (`cd backend && python manage.py runserver`) and Next.js (`cd frontend && npm run dev`) backends would be run natively instead of being run inside Docker. This also opens up other options such as running the development backends in native debuggers.

Would prefer a single command setup with no other steps still, be it `npm run dev`, `python cli.py dev`, `./start-dev.sh` or whatever. As this is a power user option, I'd say we need not necessarily support non-WSL2 Windows for this, so making it work on systems having `bash` is sufficient.

Both backends require some environment variables to be set. Preferably we would still have a single source of truth for these, be it `docker-compose.yml` or `.env` files or similar.

Nobody wants to set up their own development Postgres, Redis and Minio, so those should come from within Docker Compose still. Note that `minio` is currently setup as `network_mode: container:backend`, so if `backend` is not running, `minio` will fail. An ugly but functional workaround would be to setup `backend` and `frontend` as `network_mode: container:minio` and move the `ports:` declaration there.

As prior art and benchmark, [Outline](https://github.com/outline/outline)'s recommended way of development is setting up an `.env` file from `.env.sample` and then running `make up` that runs `yarn install`, setups the databases etc. in Docker Compose and starts the actual development server natively. We should have no need for the separate env file step and I'm not fond of Make (esp. macOS having BSD Make and Linux having GNU Make by default) but otherwise I think it's a reasonably well packaged development environment.

Food for further thought: How about other ways of running the local development environment? Dev Containers, possibly supporting GitHub Codespaces? `skaffold dev` with changed file sync on Kubernetes? We should only offer a limited number of options for which we can reasonably expect there to be actual users, but we should not constrain ourselves to what we currently have and have thought of.