Making ZeroNet ready for fuzz testing

Some codes in ZeroNet are written in Proof-of-Concept style. They are indeed very clean, but Proof-of-Concept code does not detect malicious input and report errors in a consistent manner. For example, the Web UI returns 500 server errors when it is supposed to return a 403 error. Execution of code does stop, but inconsistent output messages make automatic testing hard.

With the presence of the power of sensationalism combined with the power of trolling, any programming oversight can lead to rumor, biased representation and personal attacks, instead of solution, mitigation and plans. Given the public attention of this project, we should check for "code quality" by introducing more automated tests right now.

There are a few "public doorways" in ZeroNet. The File Server is the public doorway for anyone in the network. The web UI server is the public doorway for ZeroNet gateways. The ZeroFrame APIs are public to all potential codes a ZeroNet site can have.

These "public doorways" do not handle input data well. Sometimes the web UI [returns 500](https://github.com/HelloZeroNet/ZeroNet/issues/777) instead of 200 or 403. The the ZeroFrame Crypto API [raises an uncaught exception](https://github.com/HelloZeroNet/ZeroNet/blob/ee70e2f0224d1bc68565e363aa721eacd90142dc/plugins/CryptMessage/CryptMessagePlugin.py#L95) when the number parameters is unexpected.

Before we can perform future "battle tests" against ZeroNet, at least the error handling process of these "public doorways" should be improved. Error messages reported should be clear and consistent.