Make initial contract compilation faster + output while compiling

[Robbepop]

The last time I tested the ink-playground the compilation and especially the (initial) compilation was really slow.
This is due to many factors:

• The first build has to build the entire stack of dependencies which are quite a lot for ink! smart contracts and can easily take a minute on standard computers.
• The Rust compiling is pretty expensive due to its overall checks in general.
• Rebuilds after the first initial build are normally way faster, e.g. 1 second instead of 1 minute.

What the ink-playground could do in order to improve the initial compilation times by an order of magnitude is to pre compile the playground contract while building the image and caching all the build artifacts as it is been done in many CI systems as well.
This way we could theoretically completely avoid the long initial build time.

Haven't tested this and maybe my assumptions are wrong and not applicable from CI systems but it is maybe worth a try and would really push the usability of the ink-playground massively.

---

Another feature I'd like to see is progrress reports during compilation on the ink-playground. Currently especially those longer running compilations are taking so long without providing any feedback to the user on what is happening behind the scenes that users might think that the website just crashed. Ideally we would provide the users with constant feedback about the state of the compilation so that they know that some valuable work is actually happening.

---

Have tested ink-playground a bit more and found that not only the initial build times are slow but all build times actually are. Maybe there is no caching happening in between?

[TriplEight]

To make this more efficient, cache has to be used here.

There are two ways for using cache in your backend:

1. Pre-compile cache in the image. I.e. build some contracts in the docker-builder pattern and save that cache as is in the docker image.
   This makes a heavy image, better storing it locally, also every new rust version makes cache completely wasted, every codebase update adds some overhead to the compilation. Heavy containers will use up the host resources faster, the more users using it at the same time.
2. Build a proper caching system in backend, that would use caches exposed by sccache to i.e. redis, and CARGO_HOME and CARGO_TARGET via docker volumes.
   This is a way lighter solution and scales better.
   The downside here is that the two latter caches are prone to data-race conditions.