privat/nit — pull request #1069 by privat (2014-12-28 04:47:16+00:00)
Title: Enforce namespace rules

POC to enforce rules indicated in #1047.

So, having homonymous public modules and classes in a same project raises an error.
In the current code there was no conflicting modules. It is not surprising because for a long time the compilers refused homonymous modules even in different projects.
There was only 2 conflicting classes (on a total of 3640). This is more a good surprise since I expected a lot of conflicts. It is some kind of prof that the proposed policy is not that crazy. The two pairs of conflicting classes were `UnicodeChar` in `lib/string_experimentations/utf8.nit` and `lib/string_experimentations/utf8_noindex.nit`, and `Frame` in `naive_interpreter` and `abstract_compiler`. Some commits in the PR rename one of each pair to solve the conflicts.

For public properties, the proposed rule is to have a unique full-name "project::class::name".
There was 11 conflicts, again, it is far less than I expected.
Two of these conflict are resolved in some commits.
The other 9 are currently left as is (and the displayed error is in fact a warning).
All these remaining conflicts are a variation of the same pattern: homonymous options in refinements of ToolContext for different tools. Eg `opt_rta` for `nitmetrics` and for `nitc`.
I am not sure what is the correct way to solve these since the conflict is not only in the name but also in the behavior (a refinement of those two modules will have a broken option parsing). Maybe, behind the name conflict, there is also a bad model that misuses class refinement.