Dependency Hell for Projects

Projects in lively.next can themselves require other projects. For this reason, it is imperative that all of the required projects are to be retrieved in advance before a particular project is loaded. While looking into this matter, Linus realizes that this will apply to the required projects recursively, meaning that they also in turn may rely on other projects. We can resolve this by a fairly simple recursive algorithm. Which will all work fine, as long as we do not have two (or more) different projects requiring conflicting versions of the same project at the same time. At this point Linus realizes that we are in deep trouble since there is multiple issues arising at once:

1. It is actually rather easy to create this scenario in theory, since the usual required version matches until the next major version of project. So if two project rely on two different major versions of another project, we are already in a version conflict.
2. We further need to have a proper way of retrieving a particular version of a project reliably. While we do allow the user to tag a certain version as a "release", this is something that has to be done explicitly by the user/programmer and if there is not tag, that particular version of a project can not easily be retrieved. NPM fixes that by retrieving a published version via its index. We dont have such a index for a lively.next project unless the maintainer of such a project reliably publishes the versions to NPM or tags them avidly on github. So if we declare the tag to be the de facto version of a project that can be referenced, it should also be the one that will get entered into the lively project dependency section by the system/developer. Referencing versions in between tags is consequently not allowed.
3. Lastly we need a new way to store different versions of a project in parallel within the local_projects folder. Right now the local_projects folder is just that: A collection of different projects cloned into the lively.next setup. If we however turn it into a structure managing different versions of particular projects in parallel, we would need to beef up the structure into something like this:

local_projects 
  \_ project-1
         \_ working_copy [the latest version of this project, since we are working on it as a project in lively locally]
         \_ x.y.z [some other older version of this project, required by a different project and was installed]
  \_ project-2
         \_ x.z.1 [ again some version for this project, required by a project that was installed]
         \_ x.y.2 [ and another version of this project]

note that for project-2 we do not have a working_copy since we never created project from this repo, and it is therefore also not listed in the projects landing page

4. We need to beef up the module resolution mechanism in the client, to account for different versions. This should be fairly straight forward, it just needs to be made aware of the existence of the local_projects structure. This can be done by patching the package.config.systemjs.map at runtime. (Robin can provide more details on this when we reach this stage).