Add failure-allowed clang-4.0/libc++-4.0 build

[jagerman]

Bug #711 found the same issues that I did (which led me to #677), so I decided to convert my clang build code into a proper travis-ci build.

This adds a clang 4.0 with libc++ 4.0 docker-based build, using -std=c++1z for the build.

It's marked failure-allowed (like the gcc 7 one) since this is still an unreleased compiler with an experimental c++ standard.

The one annoyance here is that I couldn't find a pre-built libc++ 4.0 package, so had to build it from llvm-source in the build. This is reasonably quick (it adds around a minute to the build time), but is needed for libc++'s c++17 support.

[wjakob]

Starting to test C++1z is a good idea. One somewhat related thought: our build matrix on Travis CI is getting fairly big. I assume we'll eventually run into some kind of quota and our jobs will be slowed down (potentially this is happening already). Shall we remove some of the mostly redundant targets?

[jagerman]

One other thing we could do is combine some of them. For example, by having just one c++17 build that does both a clang 4 and gcc 7 build.

[jagerman]

The travis limit for build matrix size is 200, so we're nowhere near that. Throttling is applied long before that, of course, by limiting the number of concurrent jobs (across all branches/PRs), with the specific number depending on the current travis-ci load.

As far as delayed builds, during low load times there isn't much of an issue: everything builds more or less at once; we're using idle travis-ci machines. During high load, it is always the OS X builds that are the bottleneck.

So while I agree we should be good citizens by not wasting builds that aren't helpful, I don't think we're hitting limits in any practical way at the moment.

[wjakob]

Ok, sounds good. We can remove configurations from the build matrix once this becomes an actual problem. Feel free to merge this.