Extract ssf-electron startup script into new package

[BenLambertNcl]

Move the current ssf-electron script into a new package and make the script more generalized to make startup between all three APIs consistent, as discussed in #132. This will then allow us to distribute this script as a separate CLI project when we publish to npm.

[ColinEberhardt]

Continuing your idea from #132 about having a single CLI that allows you to choose which of the underlying containers to use ...

With OpenFin you can specify information about the container RVM within the app.json file, e.g.

{
    ...
    "runtime": {
            "arguments": "",
            "version": "6.49.18.41",
            "fallbackVersion": "5.44.12.20",
            "futureVersion": "6.49.19.25",
            "forceLatest": true
        }
   ...
}

This suggests that in practice you might want to specify more than just the container type.

Maybe a more generic approach would be to allow the CLI to override any property in app.json? For example:

$ containerjs app.json --runtime.forceLatest=false --startup_app.autoShow=true

One problem with the configuration file at the moment is that the OpenFin CLI tool is a thin wrapper around their executable:

https://github.com/openfin/node-openfin-launcher/blob/master/src/win-launcher.js#L23

I think OpenFinRVM.exe requires a config file as either a file or a URL, which means we not able to transform it before providing it to the exe. For the time being we could write it to a temporary file? I might raise this issue with OpenFin to see if they'd be happy to extend OpenFinRVM.exe to allow the configuration to be supplied directly as an argument.

[BenLambertNcl]

Yeah I like that idea. But I think you're right that we would need a temporary app.json file to pass into OpenFin.

[jleft]

It would be nice if this functionality could be used through a JavaScript API, as well as a CLI. The CLI could just be a wrapper around the JavaScript API, so I don't think there would much more cost to doing both.