Cache the repository priority and the corresponding prefixes regarding packages and compilers

compiler index is in ~/.opam/repo/compiler-index
package index is in ~/.opam/repo/package-index

~/.opam/repo/index is now deprecated, and editing this file to modify package priority manually is not supported anymore. Nobody was using it and it was quite a pain to maintain for no good particular reasons.
Experimental extra-fast init/update

We keep in the global state only the metadata of installed packages. So ne need to have a costly synchronization on each update.

Very untested, but at least tested on 'opam init --no-setup && opam list` wich becomes increadibly fast. Need to think a little more about the corner cases now ...
Read the cached indexes instead of computing them on every opam invocation
Add some timers to find hotspots more easily
Change the global stats thing

Now we just print the list of read/write structured files
Do not evaluate the format string when debug is not set
Add stats about external command calls
Merge branch 'master' of github.com:OCamlPro/opam

Conflicts:
	src/client/opamState.ml
Merge pull request #791 from dbuenzli/master

.install files, support for installing in etc.
Prettify an information message
Merge branch 'master' of github.com:OCamlPro/opam
'opam config var pkg:pinned' should work even if the package is not installed

Fix #743
Fix the package stats computation

This is related to #793, although not fixing it completely.
[update] Do not fail when a pinned package is not installed
[update] do not display non-installed pinned packages as a DELETED package
Add more debug info
[pin] Remove the dev-package dir when a pinned package do not install properly

Fix #768
Better handling of package removed from upstream
Fixed 'opam install' when some packages have been removed from upstream
Fixed upgrade when packages have been removed from upstream
The solver needs to know about those packages to be able to remove them, which was not the case ;
there is still a glitch if you try eg to reinstall 'a' when 'b' depends on 'a': nothing will be
done about it, since 'b' can't be recompiled. If 'c' depends on 'b', it won't be recompiled either.

But since there is no clear way of handling that situation (the only correct thing would be to remove b and c ; that would need some more work),
it seems reasonable for now to ask for an 'opam upgrade' in such pathological cases.

Closes: #740