Don't allow undefined references under Linux.

Many other systems expect this already, but on Linux the default is to
allow them.  Let's turn that off.
Tell cmake to use `-isystem` third-party includes

This adds the `SYSTEM` parameter to `include_directories`, which will tell cmake
to use `-isystem` instead of `-I` for specifying include directories. One
advantage is that compilers won't emit warnings for included files that belong
to dependencies.
Introduce nvim namespace: Move files.

Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
Introduce nvim namespace: Fix build process.

- Leave src as include dir (for includes to recognize 'nvim/' prefix).
- Change subdirectory from src to src/nvim.
- Fix msgpack generation.
- Fix some other paths to new locations.
Introduce nvim namespace: Fix relative includes.

Problem:  Some newly introduced files used includes relative to the
          current file, both of the form `include "../XXX.h"` and
          `include "XXX.h"`.
          Preferred form is relative to include root (src/ in our case).
Solution: Change includes to preferred form.
Note:     This is also done to ease next commit (prepend 'nvim/ to all
          project-local includes).
Introduce nvim namespace: Fix project-local includes.

Prepend 'nvim/' in all project-local (non-system) includes.
Introduce nvim namespace: Fix unmasked strings.h issue.

Problem:  Now that nvim/strings.h is correctly namespaced, an issue
          that had been masked until now arises:

          When compiling, we get a lot of errors because of everywhere
          the functions in nvim/strings.h are used, there's no include
          to import them.

          But, how could this compile and work previously, then? It
          turns out that:
          - In every such case, we are also including vim.h, which in
            turn includes os_unix_defs.h.
          - os_unix_defs.h includes <string.h> and also <strings.h> in
            some systems (e.g. OSX).
          - Build had been modified previously to (even when importing
            system headers), prefer equally-named local ones. That was
            in fact done as a previous attempt to solve the same issue
            we are trying to solve another way now.

          So, we were including our "strings.h" as a side-effect of
          including <strings.h> through "vim.h" --> "os_unix_defs.h".

Solution: Correctly include "nvim/strings.h" in every file needing it.
Introduce nvim namespace: Fix unit tests.

Point cimports to new locations.
Introduce nvim namespace: Fix functional tests.

Fix some paths to new locations:
- Makefile: Fix nvim binary path.
- test49  : 459: Fix nvim binary path.
- test89  :  62: Fix testdir root.
                 Fix corresponding expected result.
- test105 :  10: Testing fnamemodify to reduce path to use ~ prefix.
                 Fix faked home directory.
                 Fix corresponding expected result.
             26: Testing fnamemodify with r modifier.
                 Fix out-of-project prefix removal.
                 Fix corresponding expected result.
Introduce nvim namespace: Fix clint.

- Fix path to clint-checked files.
- Fix mechanism to calculate define guard names.
Introduce nvim namespace: Fix localization.

- Fix executable path.
- Make po file title similar as others.
Introduce nvim namespace: Fix contrib youcompleteme.

- Fix instructions to install youcompleteme configuration.
Introduce nvim namespace: Fix define guards.

Change define guards from NEOVIM_XXX_H to NVIM_XXX_H:
- Change header files.
- Change clint correct guard name calculation.
Extract cursor.h from misc{1,2}.h and memline.h
Enable -Wconversion on cursor.c