Split tests into public and internal ones

[sipa]

The current unit tests are all built against the library's internal source code directly. That means they have the advantage of being to test internal functions that aren't exposed from the library, but it also means the tests cannot actually run against the normal release build of the library.

To improve this:

• Split the tests into separate public API tests, and internal tests.
• A public test binary: public API tests, linked against the release build of the library (no -DVERIFY).
• An internal test binary: #include's the library code directly, plus public API tests, plus internal test (compiled with -DVERIFY).

[real-or-random]

I also see some value in running the internal tests without -DVERIFY. This would exercise a lot of functions with their production source.

That doesn't mean that we'll get the same compiler output as in production (but probably the compiler will be closer to production at least). And it will catch cases in our source code, in which VERIFY code introduces real differences (which it should not).

So it's not perfect but tests are never perfect. I think this is a low hanging fruit, given that it should not be a lot of effort. It will just be a second internal test binary.