Handle unexpected errors better

[tmtmtmtm]

As well as trying to do something better for specific errors that the CSV diff returns, we need to ensure that we have a good page for any error, rather than just confronting the user with a bare "Error: some impenetrable information" message.

[mhl]

I think this would be improved if any errors were presented within the prompt page. The prompter could create a subpage called /errors which would normally be empty, but if there was any error on the last run, would contain any error message. Then the prompt page template would check if that subpage was nonempty, and if so include the error message there. This would at least make the experience of seeing the error message less jarring.

Until we see more types of exceptions coming up, it might be difficult to work out which classes we should handle as special cases to rewrite the error messages to something more helpful (as in #74). But at least if we return the errors in-page, we could provide some helpful boilerplate around the errors like, "Common problems: (a) check that [CSV URL] is really a CSV file (b) check that [link to runnable SPARQL query] returns results, etc."

Does that sound worth doing?

Other obvious things to do is to check that timeouts from the SPARQL endpoint, and HTTP level errors from that (or on fetching the CSV file) are presented comprehesibly.

[mhl]

I hope this is somewhat improved now, with the new error box included in the template now, and slightly improved error messages for common cases, so I'm going to close this. If other errors come up where the error is difficult to understand, please raise issues for those so we can improve the messages.