Refactor Werkzeug requirement into flask

This is a PR for discussion is a rewrite of the code base that removes Werkzeug and replaces the server code with a Flask implementation - see issue #38 .
Sorry, I wasn't very clear here. In the first part I was suggesting that we might try to reuse some of the code from the existing `handleHTTPPost` implementation as a quick way of getting us back up and running without losing functionality. However, if adding cors support is as simple as adding the line you mentioned then lets just go with that. You can test it by running the compliance tester against the server.

For the next part, I was suggesting removing the route for `/` as this involved generating HTML, and we don't actually need that at the moment. I know it's annoying backing out of all these changes and I'm sorry to keep asking you to do it, but I don't think we should start adopting new libraries and technologies inside unrelated PRs. We need to go through the process of identifying the problem that we are trying to solve, looking at the various alternatives and then voting to decide what technology best solves this problem.

I do realise there's an irony here, in that most people wanted to go with Flask and I decided that Werkzeug would be a better option... but look where that got us!