Biggest change in this patch is that I've written the skeleton of the ZUM
server. A fun note is that I wrote it without incurring even one compiler
error or even warning, which is pretty novel. DOES THIS MEAN THAT THE ZAMBESII
API IS CLEAN AND EASY TO USE??? Find out next, in "usability testing".

* Fixed a bug in the assignment of parent-tag-IDs for devices. Parent-ID-0
  should be reserved since it is used as the "any parent" value in
  udi_enumerate_req.
  ^ Parent tag IDs are now given out from 1.
* Implemented fplainn::Zum::sZumMsg, the message type for responses from
  ZUM.
* New message stream queue for ZUM.
* Implemented the ::Callback derivative cb type for startDeviceReq sequence
  in zumServer.
* Added some more body to startDeviceReq.
* fplainn::DeviceInstance now holds a pointer to the kernel's end of the
  device's management channel.
* Fleshed out ZUM's front-end API:
  * Added prototype for startdeviceReq.
  * Added prototype for usageInd.
  * Added prototype for channelEventInd.
* Implemented front-end caller-side message preparation for all of these.
* Got rid of all of the old udi_mgmt relay and processing code.
* Fixed some include problems with the ZUM headers.
* Removed some unnecessary includes from some files.
The big news in this patch is that we can now connect to devices with
startDeviceReq, and also ZUM is able to make calls successfully into devices
using the management channel endpoint.

From next patch on we'll be working to set up the proper callee-side groundwork
for regions, and also to complete startDeviceReq.

* Silenced some excessively verbose messages from the heap which were triggered
  when a chink didn't have enough memory, and therefore other chunks had to be
  checked.
* Fixed up strerror()'s string table.
* Devices' regions now listen for events from MSGSTREAM_SUBSYSTEM_ZUDI. Probably
  in the next patch we'll write a proper handler and have them properly listen
  for MSGSTREAM_ZUDI_CHANNEL_SEND.
* Worked in proper support for setting the management child_bind_ops vector.
  The DriverInstance now sets this on execution. This means that
  FloodplainnStream::connect() now works correctly.
* Did some fleshing out of the udi_mgmt metalanguage library, but I don't think
  we'll end up using this.
* Got rid of the udi_mgmt meta specific data structures in DriverInstance. These
  corner case metadata members were relics of bad design past.
* All FloodplainnStream:: endpoint related methods now return fplainn::Endpoint,
  the base class and not the derived class, fplainn::FStreamEndpoint.

* We finally started up the ZUM Server thread!

* Implemented the udi_mgmt udi_layout_t layouts in ZUM server.
* Fixed build errors in ZUM server.
* Implemented the relay handlers for usageInd and channelEventInd in ZUM Server.
Wrote a skeleton for the handler for MSGSTREAM_ZUDI_CHANNEL_SEND. It accurately
detects the type of channel message (mgmt vs generic) being sent, and also
intercepts new endpoints without initialized endpointPrivateData pointers.

* Wrote some supporting functions in lzudi::sEndpointContext.
* Wrote some supporting functions in fplainn::DriverInit.

* sChannelMsg objects now also come with a pointer to their __kendpoint. This
  allows the region thread to use setEndpointContext on the __kendpoint when it
  has finished allocating a new sEndpointContext for the __kendpoint.
Child endpoints' eEndpointContexts now contain the bind_cb_index from their
*_bind_ops declaration.
Added a skeleton outline of what I expect the endpoint allocation code to
look like when it's done.
* All channel spawning functions now take a "metaName" string argument which
  is used to label the channel that they spawn.
  ^ Zudi::spawnEndpoint.
  ^ Zudi::spawnInternalBindChannel.
  ^ Zudi::spawnChildBindChannel.
  ^ FloodplainnStream::connect.
* fplainn::Channel now takes a "metaName" string argument which is used to label
  new channel objects.

The purpose of these changes is to enable region threads to know what
metalanguage is associated with a particular channel when they are trying to
allocate their endpoint contexts.

The next step in furthering this aim will be a series of lookup methods
for internalBop and childBop metadata, probably.
All channels are now marked as either being bind channels or non-bind channels
with specific markers for CHILD and INTERNAL bind channels.

This will be useful for the next stage, which is enabling region threads to
query the type of channel that they are trying to create endpoint context for.

* New enum: fplainn::Channel::bindChannelTypeE.
  ^ States whether or not a channel is a bind channel.
  ^ In addition, also gives what type of bind channel it is, if it is one.
Regions can now create new endpoint contexts for parent bind endpoints. We'll
probably split the code out into another function in the next patch, because
it's actually pretty voluminous.

* Fixed a bug in fplainn::DeviceInstance::getChannelByEndpoint.
As suggested by the last patch's notes, I split the endpoint allocation code
into its own function.
Minor touch-ups, prototypes for the handling functions for channel calls, and
a re-iteration through the code that detects what type of channel call has been
received.

It seems necessary to flesh out the udi_mgmt metalanguage library after all.
Next patch should focus on this.
I've now completely genericized the udi_mgmt metalanguage with its own UDI
library. Added some custom #defines that the spec doesn't detail, added some
extra code to zumServer to have it build a fast lookup cache of layouts
for the udi_mgmt ops.
Slammed together a lot of code and somehow managed to call into the
management channel for the zrootdev device. Feeling very happy.
Did some unification of the handling of the types of channel calls.

* Implemented the generic MEI call sequence.
* Corrected an error in ZUM Back End, where it was passing the wrong
  meta_ops_num to udi_mgmt calls.
* One or two new support functions in lzbzcore.
We are now able to generically and properly call into and out of a driver
on the management channel.

We will have to work on inlining next since it is necessary for us to be able
to properly call things like udi_enumerate_req. (We need UDI_DL_MOVABLE_UNTYPED
to be able to call udi_enumerate_req).

We now make use (reluctantly) of the udi_cb_t::origin member to store
privateData pointer data across calls into drivers. This opens up a point of
vulnerability for the kernel within drivers. Any driver which fails to preserve
this member will essentially "eat up" all calls that pass through it.

In fact, it's worse: drivers can cause the kernel to execute arbitrary code now.
They now intercept a call between userspace and the kernel.

* Added support for management scratch allocation.
* Added some hacky evasions in fplainn::sChannelMsg::send() to enable us to
  send messages unmolested for now.
We have now launched a successful, full round-trip of calls into a driver
and right back out.
Added support for the MA to be able to call into udi_channel_event_ind on any
channel on any device. Had to go into the fplainn::sChannelMsg::send() lower
level API.
Now finished all of the fplainn::Zum::startDeviceReq() sequence.

* Wrote the back-end call-in side of a channel_event_ind call.
* Wrote the back-end call-out side of a channel_event_complete call.
  * Added a second layer of checking in fplainn::sChannelMsg::send(). This
    will check all the endpoints in a DeviceInstance and not just those bound
    to the calling region.
    ^ It will only do this if the first check, which is region-local fails.
    ^ This enables non-primary region threads to send calls over the MA channel,
      since the MA channel is bound to the primary region.