Bolster Umbra functionality

[johnfxgalea]

This issue concerns a series of improvements to Umbra. In particular:

1. Add Umbra tests
2. Support additional granularities
3. Enable dynamic deletion of redundant blocks.

[johnfxgalea]

We also have #2130 pending, which we will address once Umbra tests are in order.

[johnfxgalea]

The shadow address of a shadow address is considered as an invalid address in Umbra.

However, Umbra (on 64-bit) has checks that ensure the shadow of an app region does not collide with the shadow's shadow when setting up memory as a form of double protection. The problem is that such checks block a shadow's shadow region from being legitimately used as a normal shadow region when we consider large scales, such as UP_4x or UP_8x.

In other words, while current (low) scales can comply with such constraints in the layout, if we consider larger scale-ups, these constraints will prevent a successful layout.

Since shadow's shadow addresses are invalid, and the checks performed are more for debugging (rather than usage checks), we should remove the checks with the benefit of supporting more scales.

[derekbruening]

Since shadow's shadow addresses are invalid, and the checks performed are more for debugging (rather than usage checks), we should remove the checks with the benefit of supporting more scales.

This is not just for debugging: a shadow mapping scheme should map any address not allocated by the application to invalid memory. Applications reference wild addresses on occasion and those should not map to application or shadow memory, causing tools to corrupt their own state or the application state. This is especially bad for tools whose goal is to detect memory bugs in applications, such as Dr. Memory.

[derekbruening]

If that invariant is dropped to make layout more flexible it needs to be a very explicit and documented decision and only tools that are ok with the reduced functionality should use it.