Revisit the instructions to fork profiling-recipe

A major shortcoming of the current approach is forking `profiling-recipe` means that you are limited to one fork (for a given GitHub account). Consider this scenario:

1. I am `user-A` and I create a repo `user-A/dataset-1` using `cytomining/profiling-template`
2. I then fork `cytomining/profiling-recipe` into `user-A/profiling-recipe` and weld it to `user-A/dataset-1`, following the instructions in README
3. I later want to create a new repo `user-A/dataset-2` using `cytomining/profiling-template`
4. I have to now used the same fork `user-A/profiling-recipe` and weld it to `user-A/dataset-2`

So `user-A/dataset-1` and `user-A/dataset-2` have to use the same fork `user-A/profiling-recipe`; there is no way around this.

One could create a branch per dataset, i.e.,
- `user-A/profiling-recipe` has a branch `dataset-1` which is welded to `user-A/dataset-1`
- `user-A/profiling-recipe` has a branch `dataset-2` which is welded to `user-A/dataset-2`

and so on. But this is getting messy!

Did you already ponder this @gwaygenomics ?

Start with the profiling-template README instructions for forking and welding profiling-recipe, then trace how the documented workflow applies to the dataset-1 and dataset-2 scenario in the issue. Define the supported workflow and update the relevant instructions so users can tell how multiple datasets should be connected without relying on an ambiguous fork setup.

Written by the indexing model from the issue text.