[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, ...).
We should make the version strictly increasing, so the version control can get a idea which build is newer one. 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`?