build: quieten the Lwt configure pass

[avsm]

When embedding Lwt in larger dune workspaces, the configure script output is one of the few pieces of information emitted to stdout. The convention in dune is to only output warnings to the standard output/error, and to document the target which can be manually read in order to debug/check.

In Lwt's case, we could quieten this output:

    discover duniverse/lwt/src/unix/lwt_features.{h,ml},duniverse/lwt/src/unix/unix_c_flags.sexp,duniverse/lwt/src/unix/unix_c_library_flags.sexp
libev ................................... skipped
pthread ............................... available
eventfd ............................... available
fd passing ............................ available
sched_getcpu .......................... available
affinity getting/setting .............. available
credentials getting (Linux) ........... available
credentials getting (NetBSD) ........ unavailable
credentials getting (OpenBSD) ....... unavailable
credentials getting (FreeBSD) ....... unavailable
getpeereid .......................... unavailable
fdatasync ............................. available
netdb_reentrant ..................... unavailable
reentrant gethost* .................... available
st_mtim.tv_nsec ....................... available
st_mtimespec.tv_nsec ................ unavailable
st_mtimensec ........................ unavailable
BSD mincore ......................... unavailable

and document in the README the _build/<config file> which can be read to get the same information.

[aantron]

I silenced the configure script unconditionally for now. The printing code is still there, but it depends on a flag. I haven't exposed this flag in any way (such as through an environment variable), because I doubt anyone uses this output. If that's wrong, we can easily expose it on request.

The emitted config files are not so useful at the moment. I think the current configure script only emits code into them when it discovers something different from the default, so it can be hard to get a full picture of everything that was checked, and the outcome of each check. We can fix that on request also, and then I would put instructions into the README.