Repair HASH_CODE support and enable it in Travis

[tautschnig]

See individual commit messages.

[smowton]

Why are you adding the new flag specifically to OSX/Clang?

[tautschnig]

Why are you adding the new flag specifically to OSX/Clang?

I just wanted to re-use some existing one rather than introducing a new stage. Would one of the others be better suited?

[smowton]

Ah, I see "one travis config," so I guess that's intentional. Still, it muddies the waters rather -- when it fails, is that an OSX problem, a Clang problem, or a HASH_CODE problem?

I suggest to deal with the myriad of non-default options, instead of piling them on different configurations in a somewhat arbitrary fashion, we should adopt a weekly (daily?) Travis cron job and use conditional builds (https://docs.travis-ci.com/user/conditional-builds-stages-jobs/) to enable these unusual configurations only in the cron environment.

This will mean PRs can appear fine and get merged if they break an odd configuration (boo!), but they consume acceptable resources while we eventually get notified of the obscure breakage, unlike some peculiar configurations which currently often break without us noticing at all -- e.g. !USE_DSTRING, or SUB_IS_LIST.

[smowton]

@peterschrammel thoughts?

[tautschnig]

I'm all for doing those via cron jobs, but where and how is one notified when something breaks?

[smowton]

Per default Travis will always notify the committer and commit author of the tip of the broken branch, regardless of the build type, though obviously whoever happens to be the most recent committer is pretty arbitrary. We also have a webhook notification set up (a la https://docs.travis-ci.com/user/notifications/#Webhooks-Delivery-Format) which would give good visibility of a breakage in the office.

We could easily add a gateway to that webhook to also mail <list of nominated people> when the failing build has "type: cron".

[tautschnig]

I have moved the Travis check to cron in this PR and have similarly cleaned up other Travis configurations in #2047.

[tautschnig]

Closing as HASH_CODE is now enabled by default (with #1992 merged).