Use `substrate-package` as the primary starting point

I have not been a big fan of the substrate-up scripts for a number of reasons:

Scripts are installed locally, and thus become static and don't pick up updates which are made to them.
They rely on cli generated packages of Substrate which are not tested to be working with other ecosystem components of Substrate.
They are error prone (since they are only bash scripts, things like a folder with the same name already existing can cause an error).
They are bash scripts, which means they dont support all operating system natively

When building documentation and tutorials, we initially relied on these scripts to get users to start building, but it quickly became obvious that this pathway was not stable enough to ensure new users run into minimal issues.

This is why I created the substrate-package which is now used as the primary starting point for most of our tutorials.

The package provides branches for different scenarios:

v1.0: a package based on the Substrate v1.0 branch, and all dependencies are tied to that branch
- contract: a node template which already includes the contract module, and also includes a known working ink! template which can be deployed to that node
- (soon to come) v2.0

The substrate-package provides known working and compatible-with-each-other version of:

Substrate Node Template
Substrate Module Template
Substrate UI (oo7)
ink! Contract template

I have seen a noticeable improvement from our users who have used the substrate-package as their starting point, and as a result I think we should make this the default pathway moving forward.

In order to make this switch, there is one fundamental requirement that we keep the package relatively up to date to what we expect to be the stable working environment. This process will just become part of the process for keeping our docs up to date. Since we want to ensure that our docs have minimal friction to new users, we will update these packages and the docs which use them together, ensuring at any point that our publicly visible development ecosystem is stable and working.

We can keep the existing scripts in spirit by simply updating them to do a git clone of the substrate-package. This would keep them truely static. I suggest in general, we put in our docs directly for the user to do git clone ... rather than running some local script. I think that this adds clarity to what is happening when a user starts a project.

paritytech / substrate-up

Use `substrate-package` as the primary starting point #35