Whenever a `CHANGELOG.md` release date is set, also create a new "next release" block with the `TBD` in the date

[Ocramius]

Feature Request

Requires #18

Discussed with @weierophinney: we probably want to prepare the next CHANGELOG.md block each time we do a release, so maintainers don't have to manually add the CHANGELOG.md template:

## $x.$y+1.0 - TBD

- Nothing.

### Added

- Even moar stuff by @ocramius, but nobody really cares :D 

### Changed

- Nothing.

### Deprecated

- Nothing.

### Removed

- Nothing.

### Fixed

- Nothing.

Not sure if we should generate the block for $x.$y+1.0, or also for $x.$y.$z+1 🤔

Q	A
New Feature	yes
RFC	no
BC Break	yes

[weierophinney]

Question: should we do this for each of:

• The release branch that just had a release (i.e., if we just closed milestone 1.1.1 on the 1.1.x branch, bump the changelog version to 1.1.2).
• The newly created minor release branch (i.e., if we just tagged 1.1.0 from the 1.1.x branch and created the 1.2.x branch, we'd bump the changelog version on the 1.2.x branch to 1.2.0).

I want to clarify before I start working on it.

[Ocramius]

Consider that:

• from the branch from which 1.1.0 has been tagged, the 1.2.x branch will be created
• when tagging 1.1.1, a PR from 1.1.x to 1.2.x will be created

I'm also a bit confused about having a 1.2.0 - TBD block together with a 1.1.1 - TBD block 🤔

[weierophinney]

I was meaning that after creating the minor branch, we'd add a 1.1.1 changelog entry to the 1.1.x branch, but NOT the 1.2.x branch; the 1.2.x branch would get the 1.2.0 entry only.

The idea is that if we DO need to create a bugfix on the 1.1.x branch, the changelog is already present to add items to.