fix race condition for waitComplete

this makes the code look a little silly, but this should actually be
the same behavior except that it prevents a race condition where two
threads could have just triggered sent in send() and then passed the
sent guard in waitComplete() but prior to either thread acquiring a
permit from the semaphore. It does indicate a need to rethink the
rest of what's going on - for instance, do we really need to check
the sent flag in receiveComplete() before releasing the gate? I'm
not waitComplete()'s main goal is or what it's warning comment refers
to so i'll leave it relatively alone for now. Meanwhile, the sent
flag may be just what I need for something else.
unimportant log fix
fix logic for detecting discardable session frames

previously we trusted that session ids would be used to start new
sessions in a strictly increasing order, however in some cases
there is a race condition between being given a session id to use
and putting the first frame on the wire/queue for that channel.

this change instead allows stream frames to distinguish between
stream creation frames and what i guess you could call config
or request-data or non-creating control frames. Until we have
a flags header, I set it up to use the 'type' header since the
type isn't needed unless creating a new stream and we can easily
afford one of the 4 billion types that we currently only use 9 of.
Could also steal a bit (eg. the sign bit) to use as a flag, but
this adds a bunch of masking logic without actually adding flag
support for the benefit of what amounts to an uncommon log message
(being able to record the would-be type of discarded frames, but
if we have some kind of distributed log processing framework we
could just match their session ids with previously recorded types).

tragically, it looks like an unknown type will not only cause an
exception but probably leave the channel state's aggregating
decoder in a permenently broken state. To that end, I have added
a property flag for disabling the creation distinction so that it
can be toggled when all mesh members are ready.

the specifics of the implementation are that the synchronize block
around 'channels' has been expanded in source handler's send method.
Therein, we use the sent flag to determine whether this is the first
frame sent by this source (and therefore will implicitly create the
remote target). This could be a volatile boolean instead of an atomic
one since updating it is not contested or even vanilla if we weren't
also supporting our friend waitComplete(), but costs are minimal.

Sources relatively rarely do any sending, and it is almost always
uncontested, so performance should be negligible. Highest contention
for 'channels' is receiveComplete for fast, wide fan outs. Given
that there were assumptions made based on channels being non-empty
or even of various specific sizes that are then immediately voided
in their guarantees, this probably also fixes some race condition
I never want to see.