Add script create-release-archive to prepare releases

[lfdebrux]

We want to edit the package.json file before making a release to remove all the stuff that users don't need. This PR adds a Node script to achieve this. Closes #1399.

This also means a small but significant change in our release process; we now rely on more than just the .gitattributes export-ignore directive to prepare a release archive for us. This means that the source code archives produced automatically by GitHub will not match our releases, and we will have to attach binaries to releases separately.

---

There are a couple of things this PR doesn't do that I think we could consider in the future, but not now.

Firstly, generating the release archive is currently left as a manual process. I think this makes sense for now, as some level of checking should take place before uploading the archive, as the script to generate the release is new, but in future we could consider automating this step.

Secondly, we are still relying on the export-ignore attribute to describe what should and shouldn't go in the release; we may want to consider changing this in future so all of the logic is in the script, and the source code archives from GitHub are more like source code archives than release archives.

Thirdly, this script relies heavily on shelling out to other command line tools, instead of using Node libraries. This is partly because it is based on a spike written in Bash, and partly because choosing the right Node library for the job is tricky. I am particularly worried about whether zip archives produced by a Node library would work in the same way as archives produced by the standard POSIX tools. But to allow the code to be more portable we should explore relying more on Node in future.

[nataliecarey]

There are some things we might want to revisit later (naming, whether to run via node FILENAME or ./FILENAME, whether to use a zip library)

But I don't see any of those being difficult to iterate on afterwards. As I see it this is a great step forward and any remaining changes would be non-breaking.