PUTs to /v2/releases/{release} should be able to handle a wider variety of requests

[bhearsum]

Currently, this endpoint has 3 modes of operation:

1. Directly update a Release with the new contents. This happens if when is not provided, and there is something different about the data passed vs. the current state of the release.
2. Schedule changes to a Release. This happens if when is provided, and there is something different about the data passed vs. the current state of the release. (Notably, it does not compare against any currently active scheduled changes.)
3. Cancel any active scheduled changes to a Release. This happens if when is not provided, and the data passed matches the current data.

Because of this, any time we want to change a Release with active scheduled changes, we have first cancel them, and then schedule new ones. If this is not done, the request to schedule new changes will fail.

In an ideal world, set_release would look at the current state of the release & active scheduled changes, and create, update, or delete the active scheduled changes to make them match the new desired state. In practice, this is horrendously complicated and has many, many edge cases, so it may not be worth the effort. My own, bitrotted, attempt at it is in https://github.com/mozbhearsum/balrog/pull/new/3.1-scheduled-change-mutation-new-releases-api.