UefiCpuPkg: ArmMmuLib: Check if Block Split Following Page Alloc

Currently, there is a bug in UpdateRegionMappingRecursive() when
guard pages are enabled and a large page is being split.

The code checks whether the page table is a block or table and
seeing that it is a block, allocates a new page table for the next
level. However, when it does this, it will call an additional recursive
call into the page table updating logic to make sure the new page table
page is mapped. In addition, when guard pages are enabled, it will
mark the guard page as RP. If the guard page is in the same block as
we are already trying to split, the recursive call will split the
block and mark the guard page as RP.

When we return to the original call, it will fill out the now
orphaned page table but never install it into the page table
hierarchy (and if it did, it would lose the guard page). This
has been observed to cause a driver's code section to still have
NX set on it and so crash when trying to execute.

This commit resolves the issue by checking if the block has
already been split when we return from the new page table
allocation. If it has, we simply update the existing table mapping
instead of trying to split the block.

The allocated page table page cannot be immediately freed, because
this might trigger the block to get re-merged, so a reference to
it is held until the end of updating this level and subsequent
levels, when it can be safely freed. It is possible that the mapping
extends across two large pages and this issue could exist on both
sides, so in the worst case we may have two orphaned tables to
free.

Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>