Add release workflow

[AlicanC]

This PR adds a release workflow that publishes packages on push to master.

Resovles #38

[rfuelsh]

@adlerjohn - looks great! great work!

[adlerjohn]

Waaaait a second. Do we want to publish to NPM every push to master, or every tagged release?

[rfuelsh]

I suggest publish npm packages with every push to master (with master being stable code) - my perspective

[adlerjohn]

What would be the version number/string that it would be published under, if it's not for tagged releases?

[rfuelsh]

@adlerjohn - as you mentioned, publishing npm packages every release is a smart move, but would be good to publish those for master as well perhaps for release v1.2.0 (just an example) something like for master branch "1.2.0-beta" for a package and then for final release "1.2.0" (these names could change of course)

again this it totally up to the dev team - whatever they prefer.

[AlicanC]

Here's what I had planned:

We have two release channels:

• Master releases: These are versioned 0.0.0-COMMIT_HASH and NPM tagged (not Git tagged, NPM tagged) as master. npm install foo installs from the latest NPM tag so these 0.0.0-x versions will never be installed unless explicitly specified (like npm install foo@0.0.0-x). They are semver valid, do not interfere with anything and helps us w/ testing.

• Regular releases: These will be our regular 0.0.1+ versions, published to the NPM tag latest. They shouldn't be transparent like master releases, meaning they should have a Git commit/tag and auto-generated changelogs from commits and they should appear on GH packages and etc. etc.

This PR sets up the "master releases" part and leaves regular releases for later. They are more complicated and I think there should be an effort involving all of our repos for that so we don't reinvent the wheel on every repo.

[AlicanC]

I've created this issue as a follow-up: #85

[adlerjohn]

Not going to block this PR, but can you document your above comment in the CI config file as a comment @AlicanC?