[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 could do that. Is timezone precision more important than casual human-readability?

I'm not sure...
Without timezone handling, the ordering of versions could be reversed if two commits in different timezones happened close to one another. For example, for 10:00 +0 and 09:00 -2, the second commit is newer, but the version would decrease when cutting off the timezone. That could confuse users and package management software.

> Or it's possible for one person get build 201412312200 while the other person get 201501010100 for the same commit.

I think the time zone of the original commit is used, not the build machine's local time zone, so that shouldn't be an issue.