The bazel -> cmake generator is currently not capable of handling
separate included generated cmake files making use of common C/C++
dependencies.
To work around this limitation, a single generated cmake is now in
place. Long-term, we should either:
* make the cmake generator handle common dependencies gracefully, or
* make the cmake generation aspect travel up `pkg_` rules `srcs`
attributes
so to avoid having to list the targets to be generated in the top-level
`BUILD` file.
Other things fixed:
* removed some warning spam about redefined `BAZEL_CURRENT_REPOSITORY`
* fixed the final link step, that was failing because `libswiftCore.so`
was not being linked.
This required a bit of an overhaul of the original integration of
JSON diagnostics into binlog.
The problem is that it is quite hard to add a kind of metadata to
binlog entries without changing its code. Another problem is that when
wanting to avoid double evaluation of logging macro arguments one
cannot really add a separate "diagnose" step easily.
The proposed solution consists in two things:
* hook into a binlog plumbing function by providing a better overload
resolution match, which happens after logging macro expansion,
bypassing the problem of double evaluation
* in that hook, produce the diagnostic directly, without waiting to
reconstruct the diagnostics entry from the binlog serialized entry.
This allows to forgo the weird category to diagnostic mapping, and now a
diagnostics emission simply happens when a diagnostic source is given
as the first argument after the log format string. A flavour of
diganostics sources with locations is then added with the same
mechanism, allowing to write something like
```cpp
LOG_ERROR("[{}] ouch!", internalError.withLocation("foo.swift", 32));
```
This reverts commit 0d9dcb161f.
This turns out to introduce a subtle bug related to destruction order
between `Log::instance()` and the `Logger` instances.
