Improve SketchAPI release process
## Build output

Build output is an archive (*.zip or *.tar.gz) containing:

- Compiled/bundled SketchAPI JS file(s), shipped in `Sketch.app/Contents/Resources/SketchAPI*.js`
- Core modules (Node.js polyfills), shipped in `Sketch.app/Contents/Resources/core-modules/**`

As part of CI, on every commit the artefact is generated and published to a unique uri (service used here is an implementation detail, but S3 is a candidate).

### Example artefact uris

For a commit:

`https://{s3-bucket-uri}/{commit-hash}.zip`

For convenience the latest commit on a branch is available via a stable uri based on the branch name:

`https://{s3-bucket-uri}/{branch-name}.zip`

## Tests

Aside from linting, type-checking and other tests etc. integration tests should be run against Sketch itself during CI.

On developer workstations this is easy to achieve by downloading or building the desired Sketch version, while on CI we'll need the ability to use a specific version Sketch - especially when trying to coordinate updates to SketchAPI that also require changes to Sketch. A suggestion for how this could work on CI by using a branch naming convention:

- Look for a matching branch on the Sketch repo
    - If found, use the Sketch build from that branch for the integration tests
    - If not found, use the version from `develop`

## Integration with Sketch build process

The Sketch build process will be need to be updated roughly as follows:

- Remove SketchAPI as a submodule
- Add configuration that defines the SketchAPI build artefact uri to be included
- Download the artefact from the uri and extract to `Resources/`

## Example workflows

### Updates to SketchAPI that don't affect Sketch

1. Open a PR in SketchAPI repo
2. Provide QA steps in PR description to validate work (maybe using `require('__pr')` or downloading the custom Sketch build from Jenkins)
3. Merge when QA and tests pass, and gather the resulting artefact url
4. Open PR on Sketch repo and update build config to point at a new SketchAPI asset url
5. Sketch is built on the PR against updated asset url

### Batching updates to Sketch repo

If working on many SketchAPI features in tandem it may be convenient to batch SketchAPI updates into a single PR on the Sketch repo to integrate

### Updates to SketchAPI that need to coordinate with Sketch updates

1. PR is opened on Sketch repo for necessary Sketch updates
2. PR is opened on SketchAPI repo, with mirrored branch naming, so the SketchAPI CI picks up the correct Sketch version
3. Work on PRs until the tests on the SketchAPI repo go green and pass QA, at this point, merge the SketchAPI PR and gather its artefact uri
4. Finally update the Sketch PR with the artefact uri, perform final QA and merge

## QA

We're proposing a QA step per pull request on SketchAPI

- Does it need separate Sketch builds for every commit? Is it too wasteful?
    - Can the Sketch build be cached? Ask Helen
    - Re-codesign after replacing the bundle `SketchAPI.js`
- Or, a way to inject dynamically SketchAPI artefact url into Sketch (not deterministic)