When cryb-test is used as a framework for another project, the compile-time test is useless since cryb-test itself will have been built with coverage disabled. Besides, it is not a reliable indicator of whether leak detection will work. Instead, check if the heap is already dirty when we first gain control.
Travis forces _FORTIFY_SOURCE, which enables warn_unused_result annotations in glibc. Some of those annotations are of dubious value; in the case of asprintf(3) and vasprintf(3), they flag code that doesn't check the return value as unsafe even if it checks the pointer instead (which is guaranteed to be NULL in case of failure, and arguably more useful than the return value). Unfortunately, gcc intentionally ignores (void) casts, so we have no choice but to quench the warning with -Wno-unused-result. However, some of the compilers we wish to support don't recognize it, so we move it from the developer flags to the Travis environment.
While there, switch Travis from Precious to Trusty.
Not only is this a slightly more logical name, but it allows us to expose the verbose flag, previously private to cryb_t_main.c, as the equally logically named t_verbose.
Unlike assert(3), which uses abort(3), this has no other side effects (before raising SIGABRT) than an fprintf() call. The test framework will catch the SIGABRT, report that the test case failed, and proceed with the next case.
It is reasonable to assume that a SIGABRT originates from a call to abort(3), either directly or via assert(3). Both the C standard and POSIX give the implementation great latitude with regard to abort(3)'s behavior, and both explicitly mention that it may close all streams before raising SIGABRT. This means that we cannot safely proceed after a call to abort(3). One could argue that we can't safely proceed after a SIGBUS or SIGSEGV either, but in practice, the damage is usually quite limited.
All further instances of asprintf() or vasprintf() in our codebase are either in libcryb-test or in individual unit tests, and in all cases, the only consequence of a failed call is that the result will say "no description" instead of either a description of the test or an explanation of how it failed. Therefore, we can simply ignore the problem and cast the call to void to satisfy gcc.
