New path 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.
le problème c'est que c'est difficile de deviner l'intention. En
particulier si il ya un un retour a l'utilisateur on voudrait pouvoir
réutiliser le vocabulaire de l'utilisateur pour lui causer.

Ainsi

~~~
$ super_tool_in_nit un_chemin
un_chemin: fichier non trouvé
~~~

est préférable à

~~~
$ super_tool_in_nit un_chemin
un_autre_chemin: fichier non trouvé
~~~

On Tue, Dec 9, 2014 at 2:29 PM, Lucas Bajolet <notifications@github.com>
wrote:

> In lib/standard/file.nit
> <https://github.com/privat/nit/pull/831#discussion-diff-21555065>:
>
> > +	do
> > +		assert exists
> > +		return stat.is_fifo
> > +	end
> > +
> > +	# Is this a UNIX socket
> > +	fun is_sock: Bool
> > +	do
> > +		assert exists
> > +		return stat.is_sock
> > +	end
> > +end
> > +
> > +redef class Text
> > +	# Access file system related services on the path at `self`
> > +	fun to_path: Path do return new Path(to_s)
>
> Pourquoi ne pas simplifier le path au passage, histoire de s'assurer que
> le truc soit lisible ?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/privat/nit/pull/831/files#r21555065>.
>