Gut the old IPC::PubSub implementation
Add a minimal Pubsub plugin

This establishes an AnyMQ::AMQP bus, and adds Jifty->bus to refer to it.
Add a basic Web::Hippie::Pipe endpoint at /__jifty/_hippie

Using the Jifty->bus AnyMQ object as its base, construct a
Web::Hippie::Pipe endpoint at /__jifty/_hippie.  This establishes
bi-directional real-time communication with the client, using wither
websockets, mxhr (multi-part XMLHttpRequest), or simply polling --
whichever the browser supports.

This can be used to send messages to the Hippie.Pipe object in the
browser, by subscribing $listener to topics on new connections (when
$path is "/new_listener").  Messages recieved from the browser are
presented as requests to "/message", and disconnects (when the browser
moves to a new page) are presented as requests to "/error".

For now, simply present a no-op endpoint.
Accept -s Twiggy, and auto-detect if we should run that rather than Standalone
Factor client handling code into its own (still no-op) module
Use AppName::PubSub as the standard app-specific class for connectons
Subscribe each connection to its own channel, for targetted delivery of messages
Store (and re-enter on each message) the request and current user
Parse and run actions passed from the client over the pipe
Split hpipe functions into their own .js file
Display hpipe-sent action results using jgrowl
Store subscriptions generated during the request to be subscribed to in the pipe
Don't bother adding action limits during subrequests
Re-indent
Split apply_fragment_updates into XML parsing and application

apply_fragment_updates consists of two halves -- walking an XML DOM to
extract response information, and applying that response information to
update the fragment on the page.  Split the function into
xml_fragment_updates and fragment_updates, so that non-XML codepaths can
reuse the latter function to apply changes to fragments.
Push fragment updates on appropriate events
Add a simple RPC class atop the message bus
Set a VERSION on the PubSub and RPC plugins
Never assign to global (non-lexical) $_, due to AnyEvent event loop

Any place wherein a postfix while assigns to $_, it is modifying the
global $_, not the lexical $_ that for and map make use of.  This leads
to the possibility of action at a distance -- particularly when in an
event-driven context such as AnyEvent.

Observed failure modes of global $_ being modified when running under
Twiggy include unpredictable server hangs and spurious errors; these
were much more common under 5.16.0 than under 5.10.1, for whatever
reason.
->clear_for may be called before any subs are configured