Dealing with corrupted ZGY files.

• Add more sanity checks on header information when opening an existing file.
• Consolidate with some of the checks done when creating new files.
• Add more unit tests that open corrupted files.
• Document known threats and how they are mitigated.

We need to be prepared for somebody maliciously hand crafting a bad ZGY file and trick e.g. a Petrel user into opening it. If a bad ZGY can cause an application to crash then this could be used for a denial of service attack. In the worst case, a corrupt ZGY could even trigger an exploitable bug. All ZGY files must be considered untrusted.

The situation before this pull request was that one crash had been reported. That crash was a simple bug that dereferenced a null pointer. Which happened if the brick size or survey size was negative. I believe it should not be possible to exploit this to do something other than just crashing some application.

Most other corrupted data would cause an exception, even before the changes. Not necessarily up front when the file is opened, and not necessarily with a meaningful message. I have done some more threat modeling and implemented a few more up front checks. As well as verifying that other potential threads have already been mitigated.