Proposed Client-app CI workflow

### Intro
This is a proposal of the CI workflow for the client (iOS/Android) apps.  It's modeled on a workflow I used when consulting which was a project in a similar setup.  The main assumptions which are similar to that project are:

- Infrequent, manually-triggered releases to App Store (ie, not a Continuous Delivery)
- Frequent beta app distribution
- Emphasis on manual testing by external users

## Setup

### Branches
- `master` is the currently released version of the app. This branch will be *protected* and only accessible via PR.
- `dev` is the current beta version (release candidate) of the app.  This branch will be *protected* and only accessible via PR.
- All other branches are to be feature branches. 

### CI Tooling
- The CI tooling with be Github Actions, with Fastlane doing the bulk of the actual work.
- Use of Fastlane as much as possible for reusability between CI systems

## Proposed Workflows

### Build PR
This workflow runs whenever there is an update to a PR
1. Build the app for testing
2. The end

### Beta
1. Increment the build number (not the marketing version number)
2. Create a changelog of all git commits since the last tagged beta release.

for app in ['joulebug', 'ikea']:
  3. Download certs and provisioning profiles using `match`
  4. Build and export the app for Development
  5. Upload the build to the Beta service
  6. Upload dYSMs and clean up the build archive
  7. Post a slack message that the workflow was successful.
end

8. Commit the build number bump with a "[ci-skip]" commit message
9. Add a Github tag of the version_number+build_number. 
10. Push the updated version number and tag to the remote.

### Release
TODO

## Development Process

### Development on Feature or Bugfix
1. Developer creates a feature branch from `Dev`. 
2. Work on the feature branch to create a new feature, fix bugs, etc.
3. Create a PR targeting `dev` to merge the feature.  This will invoke the `build-pr` Workflow.
4. After successful review, feature branch is merged to `Dev`.  This will invoke the `beta` Workflow. 

### Releasing
1. When the release is ready, developer will open a PR from `Dev` to target `master`.