Fix notorious TCP bug (EVM_DEVICE events allowing ports to GC)

Each Rebol value is implemented internally as C structures.  For the garbage collector to know which Rebol series (or objects) are being referenced by a value, this C structure must be scanned on a per-type basis.  For simple terminal types like an INTEGER! or a CHAR!, there are no embedded types.  Clearly BLOCK! holds onto the string series and other values it holds... but there are other instances, which can be subtle (a FUNCTION! holds its spec-block and body-block, for instance... as well as an internal optimized list of arguments generated from the spec.)

The [`Mark_Series()`](https://github.com/rebol/rebol/blob/4d9840f8e661e7067472e828ee6ad8dd3008b247/src/core/m-gc.c#L148) routine is responsible for sniffing the type of a REBSER, and take care of the type-specific behaviors for its elements.  In two cases it would call type-specific functions in the switch statement: for GOB! and EVENT! objects.  The GOB! function was delegated to make as many calls as it wanted to MARK_SERIES or CHECK_SERIES to handle its internal structures, while the EVENT! function was merely to return a single REBSER that it might be referencing.

This pull request does the following:

* Adds handling in the EVENT! GC marking handler to account for the case of being an EVM_DEVICE event type, in which the PORT! object being held onto is not in the VAL_EVENT_SER of the REBEVT structure, rather held indirectly by the REBREQ ->req field of the event.  Failure to account for this before was leading to crashes resulting from ports being improperly garbage collected; the "notorious TCP bug".

* While looking at the REBREQ field, I noticed a ->next field for a linked list of more REBREQs.  As the previous problem had come from a port being GC'd out from under a REBREQ, I was concerned that these other requests might be holding ports that were similarly unaccounted for.  @earl explained that if a request had made it into an event, then it had been processed and the ->next field would be NULL.  The ->next field was only used by REBDEV devices when holding requests in a pending queue.  In a "better safe than sorry" philosophy I added a `Mark_Pending_Requests()` function to walk the pending queue for the devices during a Recycle() and mark the ports they hold as used... it does pick up some ports, so this could well be an issue.  However the current layering doesn't support a way to cleanly get at devices pending queues from the GC so the "unclean" code is under **#if NEED_TO_MARK_PENDING_REQUESTS**

+ Stylizes the event GC marking routine with interface `Mark_Event` to match the working of `Mark_Gob`, for consistency.  This required removing the "static" keyword from Mark_Series which previously limited it to being called only from m-gc.c.  Potential for the routine being called incorrectly is mitigated by making sure a GC is in progress when it is called.  For consistency and ease of understanding of the code, it's reorganized so that `Mark_Gob` lives in the t-gob.c file (as the event! GC marking routine had been in t-event.c).  For code comprehensibility, moving the logic of understanding the internal structure of the types into their appropriate t-*.c files makes more sense than having that structure exported to the garbage collector.  This is a step toward a modular approach for the per-type callout routines.