[RFC] version refactor

ref #1135 #1266

- Changed cosmetic version strings (e.g., `VIM_VERSION_LONG`) to use nvim versions and verbiage. These are user-facing only, and don't affect plugins.
- Functional version identifiers (`VIM_VERSION_MAJOR`/`MINOR`/`100`) will continue to track upstream Vim for plugin compatibility.
- Introduce `NVIM_VERSION_PRERELEASE` and `NVIM_VERSION_BUILD` as optional strings controlled by cmake or `CFLAGS`.
- Rather than add another vimscript mechanism such as `v:nversion` or something, I propose we enable users to check the nvim version via `has("nvim-1.2.3")`. 
    - I stubbed this, but didn't write the logic yet.

Future considerations:

- does API version need to be separate from Nvim version? Maybe not. Because:
    - any breaking API changes will require incrementing the major-version
    - any non-breaking API change would (?) justify incrementing the minor version
- `NVIM_VERSION_BUILD` should not be set at all for release build, but we would need to establish some sort of flag that indicates this, perhaps in #1071. Otherwise we are stuck checking for various build types (MinSizeRel, RelWithDebInfo, Release, ...).
No, it is not.. what about using `date`?

> $ git log -1 --format='%ci'
> 2014-10-06 21:15:49 -0400
> $ git log -1 --format='%ci' | cut -f 1-2 -d ' ' | tr -d ' :-'
> 20141006211549
> $ date --date="$(git log -1 --format='%ci')" -u +'%Y%m%d%H%M%S'
> 20141007011549