[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, ...).
Good question.  I would not key off of the build type.  My initial thought on the matter was to have some kind of file generated (given some sort of flag to say I'm making a release archive) and include in the source release.  The file would serve as an indicator to use just the version number defined in CMake or it would contain the version information to use.  The only thing I don't like about that is that `git archive` would not produce a proper release archive (you'd need the version file in it) without running through this step, but I consider that as much an advantage (no accidental releases) as much as a hinderance.

#1071 was just about having Travis build with optimizations--it wasn't going to decide how to determine whether we're building for a release or not.  I really need to finish that line up, but there are several warnings in the optimized builds we need to get rid of.