Put together a net module - #1

From feedback,
we can avoid some allocations if we do the uncurrying explicitly.

This cleans up the FFI implementation a bit at the expense of the PS.
That seems like a fair trade-off since PS is easier to maintain than JS.

There are two bugs that got fixed in this change as well.

The first is that we were typing `Lookup` incorrectly.
The `family` is a `Maybe Int`, not a `Maybe String`.
This was silently failing but not being caught for whatever reason.
There is some kind of concurrency issue with all the callbacks.

The second is that for `Effect _`,
`ado` generates different code from `do`.
The difference here means we get the inefficient version of the code.
Rather than use `ado` and suffer the penalty,
we move over to `do` and allow for more efficient code.

All of the event handlers had the same format,
and really were doing the same thing.
There's a reason that `EventEmitter#on` is a thing.
We can use that to our advantage and write less JS!

Per review, using unqualified imports tends to lead to merge conflicts.
We can mitigate that by qualifying imports.

Per review,
we can drop the namespace on some values if we separate modules.

Having done the move,
it's not clear that the extra level of nesting was worth it.
It was one or two values that needed a suffix.
But now we've got a whole new module and another file of JS to maintain.

Oh well, we're here now.

This is the second part of movind to modules.
Again, not sure this is worth it as we end up with more code to maintain
and a less clear API overall.
We should have left well-enough alone and had six out of 78 concepts in
this module inconsistent.

Oh well, maybe someone will find a better set of values in the future.