[region-alloc] Remove custom new/delete

Doing some cleanup of my more ancient bug backlog and I ran across
this one. Follow the bug link for all of the technical details; but
the TL;DR is to remove any need for custom new/delete behavior and to
move to the standard zircon AllocChecker approach.

ZX-334 #done

Test: build and region-alloc unit tests
Change-Id: I663232d0471d2adeb2f0d6cf33bd2211a1693e96

[debug] Fix compiler nits so we can build with -Og

All changes were related to uninitialized variables accesses
that are optimized out in other builds.

Change-Id: Ide3d49fb7dcbf8211fa7a3624b7119e837c62019

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94

[zircon][mxtl->fbl] Rename mxtl to fbl

Change-Id: Ie21b6498e1bfb0a7fa0315e40b9e5c3ee78646be

[ulib][status] Use the MX_OK and MX_ERR_* mx_status_t names

Change-Id: I3ba531de766b559b8922fb4910715c630efc9b82

[assert] Introduce MX_ASSERT

Make magenta style asserts public and defined in magenta/assert.h. Convert
usermode code to use the MX_(ASSERT|DEBUG_ASSERT) versions.

Change-Id: Iec8cc20f9c577cee50bc72bd820d4c1b604b8a86

[mxtl] Remove reference-taking variants of AutoLock constructors

Change-Id: I3f2c3a6ff88a4004448e9e90668541203d1ff50e

[region-alloc] Remove RegionAllocator::Region overhead.

RegionAllocator::Regions already know which RegionAllocator they
belong to, and therefor they implicitly know which SlabAllocator they
belong to. Switch to using the MANUAL_DELETE flavor of
SlabAllocators<> to avoid the extra pointer's worth of overhead
involved in tracking which SlabAllocator<> each region came from.

Change-Id: If3556a606138722dc3e61ea12f291b9a6ff394c5

[region-alloc] Remove custom slab allocator from RegionAlloc

Make it use the generic mxtl::SlabAllocator<> instead

Change-Id: Ifa340d816af202fb8566b52a9e836bc55ea95e73

[utils] Add synchronization to region-alloc library.

Protect RegionAllocators and RegionPools from thread safety issues
using mxtl::Mutex wrappers. While this limits the application of
region-alloc code to non-IRQ contexts, it greatly simplifies issues
surrounding thread safety when using the unique_ptr<> pattern for
automatically releasing regions back to their owner RegionAllocator
pool.

Change-Id: Ib509ba59d5e9a850ddd07e874b2862f54e4a3dc5

[region-alloc] Fix release builds.

For some reason, gcc's -Werror=maybe-uninitialized picks up this
non-bug, but only in release builds and not in debug.

Change-Id: I3ca9975e11dd1de3bdea7947cc88deb64b57841c

[utils] Allow subtraction from available region in region-alloc.

Change-Id: I71ce1b2c914c21ebe8cc306a05147bff0cb7141c

[utils] Allow adding overlapping regions in region-alloc

When adding regions to the set of available regions in the
region-alloc utility library, add a flag which permits the user to
specify that it is OK for the regions being added to overlap with the
existing available regions. If the flag is set, the set of regions
available for allocation will become the union of the existing regions
and the region being added.

It is still not OK to attempt to add a region which intersets any
currently allocated region.

Change-Id: I64d19bbea7197a6ef38ed92cb3743e4392d35812

[utils] Add a region allocator utility library.

Add a small utility library (and tests) to manage allocating regions
of a 64-bit space. The general idea is that a user of the library can
create an allocator and add some (non-overlapping) regions to it.
They can then allocate regions from the available regions in the
allocator, either by size and alignment requirement or by specific
base address and size.

C and C++ APIs are provided. The C++ API depends on mxtl, but does
not depend on any particular implementation of new. Instead, it
explicitly uses malloc/free under the hood. Bookkeeping allocation is
done using allocation pools which allocate and carve up slabs of
memory (placing the results on a free list) in order to minimize the
frequency of trips to the heap and avoid heap fragmentation. Limits
can be placed on the total size of a pool, and pools can be shared
across multiple allocators allowing multiple applications in the same
binary to compartmentalize their memory impact.

Change-Id: I007322b66f60c2e520e45013e9c3352a60557af0