Ensure that all parsers that add tree items uphold the required pre- and post-conditions

[NikolajSchlej]

There is a set of unformalized-as-of-today rules that all parsers in UEFITool that are able to add new tree items strived to abide to, now it's finally time to not just formalize them, but to write them into law by writing the necessary code that will check the tree for breaking the rules, and complain loudly about it.

I expect that we will find some nasty corner cases in existing ME parsers (//TODO: add padding anyone?), and will have to rewrite the (currently disabled) AMD parser a bit before we could close this issue, but I prefer to treat every breach of that contract as a bug to be fixed.

Now let's formalize those pre- and post-conditions I keep talking about:

• after the input file is provided, the tree always has a single root item (be it Intel image, AMD image, UEFI image, or something else), that always has a base of 0, offset of 0, and size of the whole image size. This trivially covers every single byte of the input file.
• every byte of uncompressed parent item body needs to also be represented by one and only one child item, and size_of(parent_header) + sum_1_n(size_of(child_n)) should always be equal to size_of(parent), aka "paddings of appropriate sizes need to be inserted before/between/after other kinds of child items to ensure that every byte of the parent item is covered". All such child items must have valid base, offset and size values.
• the special case of compressed parent item should be handled on case-to-case basis, but every child item of a compressed parent should never have a valid value of base, but should still have valid offset and size.
• the special case of possible overlapping items (i.e. multiple entries in various tables covering the same exact byte range inside the image) should be handled on case-to-case basis, but it must be ensured that such a range is added to the tree only once.

[NikolajSchlej]

First step towards this: d684e4b

Now it's much harder to lie about full/header/body/tail size of an item, because it's getting populated automatically instead of being obtained from parsers every time. Now the only source of that information are the actual byte arrays inside tree items.

[NikolajSchlej]

Nope, the very first attempt at actually implementing that constraint checker immediately shown that a lot of UEFI PI structures use not only paddings, but also alignment bytes, and those had never been added into the parsing tree, which immediately destroys the possible totalChildenSize == parentBodySize check implemented without accounting for it.