all changes needed for mac app store

[wkelly17]

Alright, this was far more onerous than I was expecting but that's working in a an unfamiliar domain for you. In summary:

Basically. this chapter from install4j, with the following notes:
https://www.ej-technologies.com/resources/install4j/help/doc/concepts/macosAppStore.html

There are now two build jobs.
The old one is the same. The new one "mac_store_build" has the following changes:

• Includes provision profile (in OP, like all env and secrets)
• The keystore p12 has 2 other app store related certificates in it
• Apple doesn't fully respect semantic versioning (thanks Dan...). So, the +sign run of the version is chopped off in this build to conform to store requirements. As A result, each build passes explicit build ids for its builds as well.

Speaking of store requirements.
Once you've used a version (3.1.28, which is where this is branched from), you can go down. In my debugging I accidentally used up 3.1.28, and then I accidentally used like 3.1.29 and then started using some like 3.1.2901, 2902, 2903... etc; As a result, @jsarabia, I was hoping we could just tag this a 3.1.30, adn then whatever is currently in dev will become 3.1.31 etc;.

At Dan's suggestion, this mac_store_build.yml only runs on tagged releases, so it's not in the space for using with testflight to really run our testing through there. For going to the store, whenever we have a new release, we'd just want to let me (or Dan) know, and we could grab the pkg pretty simply and upload it to the app store. Now that it's actually setup with the correct cerst and config, should be pretty quick (i.e. 60 seconds) to push new versions to app store.

Lastly, I would like to test this with David or someone. I don't the full extent of our tests outside of what's automated, but app store apps run in a sandbox differently than dmgs, so It'd probably be worth checking to make sure it does what's expected.

Lmk if y'all have any questions or anything.
Thanks

---

This change is 

[danparisd]

Left a couple comments around how to handle the conditional nature of this workflow. Otherwise looks good.

[danparisd]

make this only push/pr for the main branch where production releases are made. eg,

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main

[danparisd]

Jobs can run conditionally, so this is probably where I'd put the conditional to only run if it's tagged.

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution

I guess this would mean you'd need that sort of if on each job. Curious your thoughts.