Test BoringSSL refcounting

[joshlf]

Currently, we have a few small smoke tests to make sure that we don't decrement BoringSSL refcounts too far. However, we have no tests to ensure that we decrement refcounts far enough (in other words, that we don't leak resources by leaving unused objects allocated and constructed).

We should also test the latter. The way to do this is probably to figure out how to inspect the refcount on a BoringSSL object and use that mechanism to ensure that the refcount on these objects is 1 when we only hold a single reference. That said, perhaps there's a better way to do this.

EDIT: Let's first try to see if we can enable ASan (#15), which should address this.

[davidben]

ASan should be able to check both of these without reaching into BoringSSL's private structures (unsupported). If you over-decrement, ASan will report a UAF. If you under-decrement, ASan will report a leak.

[joshlf]

OK, I've opened #15 and I'll update the first comment to reference it.