travis: 'error' type examples slow down Travis-CI by 2-3 minutes

[rbasso]

I just noticed that the leap example error-nosig, which is the only error-type example in the repository, makes Travis-CI identify changes and repack the cache, delaying the rebuilds between 2 and 3 minutes before reporting it as successful.

" exited with 0.
store build cache

change detected (content changed, file is created, or file is deleted):
/home/travis/.foldercache/leap/error-nosig/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/stack-build-cache
/home/travis/.foldercache/leap/error-nosig/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/stack-cabal-mod
changes detected, packing new archive
.
.
.

As we OK with that or should we do something about it?

[petertseng]

For someone who doesn't like having to wait N minutes * M builds if there are M pull requests in action (like myself in #445), it hurts by M * delta N. Although I just octomerge to set M to 1, so it's hurting me so much less that I didn't notice it yet.

The only reason I added any arbitrary error case in #477 is simply to test that the error case works. I didn't have any particular error case that I actually wanted to test (I do have fail tests that I want to test, but I don't care about error), so I picked any arbitrary one, since error was suggested in #397 . It can be deleted, since it is not pulling its weight.

But if we want to test an error case in the future, we could consider deleting its directory so that it doesn't affect the cache.

If we have no specific error cases we want to test, I suggest deleting the relevant https://github.com/exercism/xhaskell/blob/master/bin/test-example#L64-L69 lines from the script, since it doesn't seem right to have untested code in the scripts.