[spec] build shrinkwrap.json into built js file

[villadora]

do version fix during build, make a package as closure of all the information that it contains.

additional config value may added as shrinkwrap:

define('a@1.0.0', ['b@~1.0.0'], factory, {
   shrinkwrap: {
        'a@1.0.0': [ '1.0.0', {
               'b@~1.0.0': [ '1.0.1', {
                     'c@^1.2.0': ['1.3.0']
               }]
         }]
   }
});

which make shrinkwrap info only be contains in the package itself

As it's no longer json configs, shared objects can be represented as:

var a = ['1.0.0'];
{
    "b@1.0.0": [ "1.0.0": {
        "a@~1.0.0": a,
        "c@~0.1.0": [" 0.1.0", {
            "a@^1.0.0": a
        }]
    }]
}

and cyclic dependencies could be represented as:

var a = ['1.0.0', {}];
var b = ['1.0.0', { 'a@~1.0.0': a }];
a[1]['b@~1.0.0'] = b;

But this kind of code might be hard for auto generator, candidates can be:

• use ref
• use self description with: ~ and last element of array to indicates the scope, may looks like circular-json but with scope additions

For normal modules, the resolved map should flat, as a global object:

{
    "a": {
        "~1.0.0": "1.0.1",
        "^1.0.0": "1.2.0"
    }
}

Pros

• Loading shrinkwrapped modules become simple
• Config become simple
• Shrinked logical now in one place
• Self encapsulated for modules
• ...

  Cons

• Circular is hard to be generated in builder
• Won't get optimized object references across two shrinkwrapped modules, which means the module can not be shared between two shrinkwrapped facades
• WeakMap is not fully supported, loader hard to decide whether should load the same module even the descriptions of modules are the same object.
• ...

[kaelzhang]

So, close for now