Implement DQLITE_VISIBLE_TO_TESTS properly, or get rid of it

[cole-miller]

In #511 I added the DQLITE_VISIBLE_TO_TESTS attribute to functions and globals that are not part of our public API but are currently used by integration tests. It currently expands to __attribute__((visibility("default"))), so other consumers of libdqlite can also see those symbols. It would be good to figure out a way of arranging that those symbols are visible only when building our integration tests, or alternatively to fix the integration tests so that they don't use non-public stuff (for example, by moving some things to a static library that's built into both libdqlite and integration-test).

[freeekanayaka]

It seems that the DQLITE_VISIBLE_TO_TESTS is used to expose mostly internal functions around client functionality. Once the public C client has been put in place, I think we should be able to use that instead, and get rid of the majority of DQLITE_VISIBLE_TO_TESTS instances. The few other DQLITE_VISIBLE_TO_TESTS uses seem to tweak internal state and can probably be accomplished by introducing a dqlite_server_test_control() function similar to sqlite3_test_control().