Explicitly whitelist branches for generating releases on feedstocks

The main idea is that users sometimes don't realize they need to fork a feedstock and PR a change to avoid a release. If we document this, that problem will happen less frequently. However, it would still be easier for users to make a change if they didn't have to fork.

The idea behind having multiple branches on the original feedstock is to allow for having multiple versions supported simultaneously (e.g. a version 2 and 3 of Python). That being said, it is more often in practice that a maintainer works on one version and generates fixes for it than it is for them to add multiple versions. To make their lives a little easier, we should consider cutting a few steps out of this common maintenance process.

The proposal here is a follows. Releases should only occur from branches that we explicitly specify as releases branches. Any branch not on that list does not generate a release. Possibly we may want it not to build at all (unless it is in a PR). In other words, release branches must explicitly be whitelisted. All other branches are automatically blacklisted. This change will allow users that wish not fork, but do maintenance within the repo here the option. It also will avoid unpleasant surprises that a release was generated from some partially completed work.

The process for whitelisting should still be simple. This could be a list in `conda-forge.yml` that specifies the branches. By default, this should only include `master`. Users could add more branches to this list, but ~~may need to re-render with `conda-smithy` depending on the implementation detail~~ (this could be a very problematic implementation detail as it could result in everything ceasing to deploy when merged). The net effect being it is still quite simple to add a new branch for release. Also, this still can be done in a PR and be enabled when merged.

Using this proposal, it requires an explicit intentional action to create a multi-release feedstock. However, the effort required is still minimal, but is a bit closer to proportional with how often this is used. Also, this avoids people accidentally releasing things with this workflow. Plus, it removes the requirement of forking from maintenance simplifying maintainers lives in the process.

Potential syntax:

``` yaml
# conda-forge.yml
...
deployment_branches:
- master
...
```

Please share any thoughts and feedback on this.