New File API (incomplete proposition)

As previously discussed with @privat and @R4PaSs, this is only a partial and incomplete propostion for a new file access API. Because it is incomplete, some doc and comments are missing. At this point, please only review the API structure.

It provides new features:
* All file/path related services are to be stored in `FilePath` instead of `String`. The goal is to store there all the methods previously beginning with `path_` and others like `rmdir` and `files`.  The calls to the new API take the form of `"/tmp/somefile.txt".path.delete`. You will notice that this PR do not yet move all those services but only a subset as an example, this will be completed if it is appreciated.
* Easy file opening (for read or write) with: `"/tmp/somefile.txt".path.open_ro.read_all`
* `FilePath` stores the concept of full path and filename. Calls to `/etc/somedir/".path.files` returns an array of `FilePath` which can be `to_s`ed to get the full path and calling `filename` returns only the file name.
* The native `stat` structure is now renamed to `NativeFileStat` and protected within a Nity finalizable `FileStat`. The new `FileStat` could be implemented differently by platform.

Open questions:

* Should we use POSIX names or friendlier and nitier names? Some related sub-questions:
    * Rename `Path.delete` to `Path.remove`?
    * Rename (or bring back) `is_regular_file` and `is_link` to `is_reg` and `is_lnk`
    * Rename `stat` to `status`?
* Rename `FilePath` to `Path`? There is currently a conflict with a private class by @R4paSs, but it could be renamed.
* Should we prefer `Text.file` instead of `Text.path`? I chose `path` because there may not be a file at that path. This choice also affect the next question.
* Should we move _all_ the path related services to `FilePath`? This would include `relpath` (which could be `Text.path.relative`), `simplify_path`, `dirname` and `basename`. It would only be logical to do so if the API is accepted.