[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, ...).
> How about reporting the version as 0.0.0-alpha-<commit count>-<commit sha>, while <commit count> is calculated by git rev-list --count HEAD?

No, that will take an increasingly longer time to compute as more commits land.  If you need something that increases regularly, use the date:

    git log -1 --format='%ci' | cut -f 1 -d ' ' | sed -e 's/-//g'