Improve the CI

[bzz]

Potential action items:

• make release job more modular Migrate to SDK.v3 - protocol.v2 with decode #84 (comment)
• do not install all native dependencies (presumably, some are only necessary for cross-compilation)
• do not install all recommended drivers for bblfshd
• check if building in separate job on OS X vm is faster then cross-compile and add it to normal CI flow

[ncordon]

IMHO we should split the builds for Linux and macOS. We are applying a list of patches to be able to cross compile in Linux right now. And we could bump the minimum OSX_VERSION_MIN in .travis.yml to at least 10.7 (right now is 10.6). As documented in osxcross, versions lower than 10.7 do not include stdlib. We have to bootstrap it by hand (we are downloading one included in xgo which corresponds to macOS SDK version 10.11, that's way just updating SDK in travis.yml does not work, and it is because we are bootstraping this library but also because we are not using modern enough OSX version). And we have to patch it (since we are using unordered_map and new versions of osxcross fix it in their build.sh file).

Also after all that costly process, I think stdlib corresponds to OSX version 10.7 anyway 🙈 (the message about 10.13 is coming from libuast most probably):

ld: warning: object file (src/main/resources/libuast/libuast.a(000000.o)) was built for newer OSX version (10.13) than being linked (10.7)

For me it makes sense to spend some time here and redesign the CI workflow. We are accumulating efforts trying to cross compile the macOS release. Instead I propose:

• Test stage:
  • Two separate builds, one with Linux other with macOS
• Release stage:
  • One job in Linux that builds libscalauast.so
  • One job in maxOs that builds libscalauast.dylib
  • One job that push to Sonatype. Maybe this cannot be done directly to collect the libscalauast.{so, dylib} generated by previous levels and we need some intermediate step as pushing those files to GitHub releases