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.

从 issue #777 中描述的 web UI 行为以及 plugins/CryptMessage/CryptMessagePlugin.py 中的 ZeroFrame Crypto API 入口点开始。将 File Server、web UI server 和 ZeroFrame 的 API 与其现有测试和错误路径对应起来。完成的标准是：格式错误或未经授权的输入能够产生清晰、一致的响应，不会引发未捕获的异常，并且为受影响的公共入口提供自动化覆盖。

由索引模型根据 Issue 内容生成。