Drop race detector from Travis builds

[rtfb]

We do not have a single go statement in Blackfriday code, -race does
nothing for us, but burn CPU cycles (and it hurts because we're hitting
timeouts on full test runs).

[rtfb]

@dmitshur, please take a look. I propose we drop -race from Travis runs. With #428 I'm doubling the amount of tests and we're hitting the default 10m timeout very hard. As far as I can tell, -race does nothing for us, since we have zero parallelism, it only makes tests more than 10x slower (~420s vs ~40s on my laptop).

[dmitshur]

The arguments to drop it, in this specific case at this time, SGTM. However, I have two followup points:

1. I think all reviewers merging future PRs will need to be mindful of this, and if there's ever a go keyword added to the codebase, we should actively consider re-adding -race.

2. I don't see a reason why we shouldn't be running tests in parallel by using t.Parallel(). We're currently not doing that at all. From a quick local test on a quad-core laptop, allowing tests to run in parallel speeds up go test -race gopkg.in/russross/blackfriday.v2 from 156.058s to 77.826s. I'm seeing only 200% CPU usage for most of the time (out of 800% max, given 8 threads), so I suspect there are 2 tests that take the longest to run, and can likely be sped up even further by breaking up into sub-tests that can run in parallel.

[rtfb]

By zero parallelism I meant that all the logic of Blackfriday runs in a single goroutine, and there's no data that could race. But a point about speeding up tests by running them in parallel is very good one, I filed an issue for it.

Thanks!