Add Boost.Build variants for UBSan-enabled builds

[mloskot]

(NOTE: Assigned to self - if accepted, I'd like to merge myself. Thanks.)

Description: what does this pull request do?

The build variants enable group of checks offered by clang
UndefinedBehaviorSanitizer detector.

Add sanitizers suppression file in .ci/blacklist.supp based on copy of the file from Boost.Beast.

Update Travis CI:

• Add build jobs for each of the three new UBSan variants.
• Display COMPILER and VARIANT first as these two are most important
  details while inspecting the build matrix
  (TOOLSET can be derived from COMPILER).

Tasklist

• Set The Grand Merge milestone (@stefanseefeld OK?)
• Review
• Adjust for comments
• All CI builds and checks have passed

---

I've built the UBSan variants and there are issues - to be checked/fixed after this is merged.

[mloskot]

First build of this PR at https://travis-ci.org/boostorg/gil/builds/394728281 suggests that variant=debug,release merge can cause timeouts.
However, it's interesting that the 1st (GCC 5) and 4th (clang 3.9) builds completed in ~20 minutes.
I'd keep variant=release only really or may be have one debug with the latest GCC.

Question

Do we really need to build both variants, debug and release for every compiler version?

[stefanseefeld]

what is the nature of the timeout ? Would it help to split builds up, so "release" and "debug" would be separate builds ? (Given that we discovered certain failures only with particular compiler flags (optimization, notably), I'd very much prefer to keep the coverage. If any, we should remove the debug builds.
And yes, I observed excessively long compilation times with certain gcc versions (interestingly, more recent versions).

[mloskot]

@stefanseefeld

what is the nature of the timeout ?

Not sure I get your question, but https://docs.travis-ci.com/user/customizing-the-build#Build-Timeouts

When a job produces no log output for 10 minutes.
When a job on a public repository takes longer than 50 minutes.
When a job on a private repository takes longer than 120 minutes.

Would it help to split builds up, so "release" and "debug" would be separate builds ?

That is what we have been doing, and I proposed to merge the two variants into single build job.

I'd very much prefer to keep the coverage.

No problem, I have reverted the merging of build variants and the build jobs coverage is back to the original, see https://travis-ci.org/boostorg/gil/builds/394879984

And yes, I observed excessively long compilation times with certain gcc versions (interestingly, more recent versions).

This is quite a curiosity. Also the latest build above shows that GCC 5 is blazing fast comparing to 6 and 7. Perhaps, with GCC 6 and 7 we generate more detailed warnings - I imagine, stdout/stderr I/O may slow things down. If I find a moment, I will look at the detailed logs and compare them.

[stefanseefeld]

This looks great. Thanks for the effort !

[mloskot]

Thanks for the review.

To summary:

• Travis CI build jobs ubsan_integer and ubsan_undefined should fail due to issues detected by the sanitizers in GIL - https://travis-ci.org/boostorg/gil/builds/395130073
• AppVeyor build jobs should pass