opam lint should print a warning if "setenv:" is used

[mato]

From today's discussion in #opam regarding the behaviour of the newly-introduced setenv: directive in OPAM 2:

This directive was introduced in order to support compiler packages (to set CAML_LD_LIBRARY_PATH, OCAML_TOPLEVEL_PATH and similar). The behaviour of setenv in its current form is to export all setenv directives for all installed packages into the user's environment (via opam env).

This behaviour can have unintended consequences where any installed package's setenv can subtly break or alter the build for any subsequently installed package, or any commands the user runs from the shell with the OPAM environment.

Therefore, we agreed that the use of setenv, while necessary for compiler packages, should be discouraged, and opam lint should print a warning to alert maintainers if they use this directive. (Ideally also once OPAM 2.0 packages can be submitted directly then the equivalent of Camelus should pick this up).

Once opam gains support for running package builds from a clean environment (and thus separating the "user environment" from the "build environment" entirely) this warning can be removed.

[mato]

Adding some of the discussion verbatim so I don't forget the other points I made. Also /cc #3181

16:53 mato Well, there are two problems I see. 1) is malicious abuse, which I'm kind of glossing over since that would a) hopefully be caught in a review process b) isn't "new" in the sense that you can do anything like that today just by doing something malicious during package build. 
16:54 mato 2) is the subtle case of a package "accidentally" breaking some other package through a `setenv`, which in combination with the feature of exporting everything into the user's shell becomes even more of an issue. 
16:54 mato plus adds a lot of complexity as you see yourself (reading #3181) 
16:56 avsm @altgr we could offer an option for `opam exec` to execute a binary with sandboxing enabled 
16:58 mato For me `setenv` would make sense if opam always started with a "clean" environment, and no exporting of `setenv` into the user's environment was done. 
16:59 mato And yes, in that case `opam exec` could indeed be a gateway to "run this with the opam environment" (sandboxed or not) 
16:59 altgr allowing to start from a clean env (and later on, making that the default) is planned