Determine BoringSSL's SSL struct offsets for it's openssl 1.0.x compatibility

[ddelnano]

Is your feature request related to a problem? Please describe.

In #569 I've expanded Pixie's TLS tracing to include binaries with statically linked BoringSSL. At this time it only works for binaries linked with BoringSSL targeting openssl 1.1.x compatibility, however, it would be easy to extend this to support for 1.0.x. As mentioned in BoringSSL's docs it has been tracking openssl since 1.0.2 according to this (also copied below).

BoringSSL's OPENSSL_VERSION_NUMBER matches the OpenSSL version it targets. Version checks for OpenSSL should ideally work as-is in BoringSSL. BoringSSL also defines upstream's OPENSSL_NO_* feature macros corresponding to removed features. If the preprocessor is needed, use these version checks or feature macros where possible, especially when patching third-party projects. Such patches are more generally useful to OpenSSL consumers and thus more appropriate to send upstream.

In some cases, BoringSSL-specific code may be necessary. Use the OPENSSL_IS_BORINGSSL preprocessor macro in #ifdefs. However, first contact the BoringSSL maintainers about the missing APIs. We will typically add compatibility functions for convenience. In particular, contact BoringSSL maintainers before working around missing OpenSSL 1.1.0 accessors. BoringSSL was originally derived from OpenSSL 1.0.2 but now targets OpenSSL 1.1.0. Some newer APIs may be missing but can be added on request. (Not all projects have been ported to OpenSSL 1.1.0, so BoringSSL also remains largely compatible with OpenSSL 1.0.2.)

Describe the solution you'd like

Determine the offsets used for application linked with BoringSSL 1.0.x and update Pixie to handle that case.

Describe alternatives you've considered
N/A

Additional context
See this comment for more details.

[ddelnano]

We will be addressing BoringSSL support in #692 and through a different mechanism than as described in this issue.