Beta versions support: SxS support, in-app env/instance display (#1606)

* Script for beta config; unique data dir, in-app env/type display

To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.

The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.

Note: Beta builds can be installed alongside production builds.

As part of this, a couple new bits of data are shown across the app:

- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)

These are shown in:

- The window title - both environment and app instance. You can tell
  beta builds because the app name, preceding these data bits, is
  different.
- The about window - both environment and app instance. You can tell
  beta builds from the version number.
- The header added to the debug log - just environment. The version
  number will tell us if it's a beta build, and app instance isn't
  helpful.

* Turn on single-window mode in non-production modes

Because it's really frightening when you see 'unable to read from db'
errors in the console.

* aply.sh: More instructions for initial setup and testing

* Gruntfile: Get consistent with use of package.json datas

* Linux: manually update desktop keys, since macros not available

about.html

@@ -30,6 +30,20 @@ a {
   document.write('v', window.config.version);
 </script>
 </div>
+<div>
+<script>
+  var states = [];
+
+  if (window.config.environment !== 'production') {
+    states.push(window.config.environment);
+  }
+  if (window.config.appInstance) {
+    states.push(window.config.appInstance);
+  }
+
+  document.write(states.join(' - '));
+</script>
+</div>
 <div>
   <a href="https://signal.org">signal.org</a>
 </div>