Tracking: release 1.0 and adopt semver

[cschleiden]

At some point I want to release a version 1.0 of this library and start following semver for breaking changes. This issue tracks the work I think is necessary for that.

### Tasks
- [ ] #244
- [ ] #200
- [ ] https://github.com/cschleiden/go-workflows/issues/263
- [ ] https://github.com/cschleiden/go-workflows/issues/280
- [ ] https://github.com/cschleiden/go-workflows/issues/260
- [ ] https://github.com/cschleiden/go-workflows/issues/335
- [ ] https://github.com/cschleiden/go-workflows/issues/315
- [ ] https://github.com/cschleiden/go-workflows/issues/28
- [ ] https://github.com/cschleiden/go-workflows/issues/349

[cschleiden]

Added the latest batch of bugs and partially implemented features I'd like to fix and finish before releasing 1.0.

[decibelcooper]

@cschleiden Are there any tasks you would like help with to drive this project to v1?

[cschleiden]

@decibelcooper for now I've only got a couple more features planned for 1.0. I bet there are some bugs that need to be fixed, but I got it with the current plan.

[cspotcode]

Is 1.0 going to be the next version, or are you planning other pre-1.0 releases? I ask because I'm hoping to use the new "queue" feature for our side-by-side deploys, so I'm trying to estimate a realistic schedule for that. If I shouldn't expect a stable release in the near-term, then I can use side-by-side backends as a stop-gap.