Expose major/minor/patch and custom parts in all configurable strings

[florisla]

Closes #35

Currently, only serialize has access to the part identifiers such
as {major}, {minor} and {patch}.

This change exposes them also to other configurable strings, providing
more flexibility in formatting:

message
tag_name
tag_message
replace

To be intuitive relative to the existing current_version
and new_version identifiers, these are named current_[part]
and new_[part].

Additionally, to be intuitive relative to the [part] identifiers
available in serialize, the new_[part] identifiers are also
exposed as [part] without the new_ prefix.

[florisla]

@c4urself How do you feel about this one?

If it has no chance to be merged in, I should stop using it here ;-)

[c4urself]

@florisla -- I like it, haven't had a need for it myself but definitely see why some others might. Can we add a test for the replace functionality you were planning on using it for?

[florisla]

It seems the tests (edit: i.e., all test_cli.py tests) are not compatible to pytest 4.0.0. On 3.10.1 it passes with deprecation warnings.

[lycantropos]

If I understood correctly this will allow us to handle cases like

https://cmake.org/files/v3.9/cmake-3.9.5.tar.gz

which after bumping minor version becomes

https://cmake.org/files/v3.10/cmake-3.10.0.tar.gz

?

[florisla]

If you have a special bumpversion configuration file to track the cmake version, yes.

You can use the parts (major/minor/patch or custom) independently everywhere you like. So you could also create a commit message like

Move to cmake major version "3", minor "10", patch "0" from 3/9/5

[florisla]

I've just rebased on #46 so the unit tests now use 'vcs' as a fixture.

[florisla]

Rebased on master.

Let me know if you'd like to see other changes.

[florisla]

Rebased on master.

[florisla]

I've rebased on master and updated the Readme to reflect the changes (+ some cosmetic fixes).

[andrew-glenn]

@c4urself - any chance this can be merged? :)