Fix unnamed sockets

See merge request !3

Previous approach, reverted in commit c7cf2ca0, would break unnamed
sockets - since it assumed there would always be an interim step were
one would first name an unnamed socket, before "listen" / "connect".

Instead of using the same approach as the "tcp:" scheme in Redox's
netstack, which requires an extra mapping of temporary unnamed sockets,
handle the different use cases in dup(). Thus, if a "buf" is provided
that's not a "connect" or "listen", it must be a new path for turning
the unnamed socket into a named socket and should be handled as such.

This reverts commit 9526ffa8.

Support AF_UNIX sockets

See merge request !2

While supporting AF_UNIX, once an accept() is called in relibc, in turn,
a dup() is also called with "listen". While processing this ipcd
effectively creates a new handler, losing track of the path of the
previous handler.

However, it is important to keep this path in the newly created Handler
as well, so the socket can be queried later by relibc (when calling
fpath()) and fill in appropriately its sockaddr_un struct.

Similarly to how the "tcp:" in Redox's netstack supports opening a first
empty scheme, only to later on being dup()'ed and set with an
appropriate path, this follows the same approach - a map of NullFile
structs is kept and initially associated with an id. Next time dup() is
called, the true Handle is created, keeping the same definitions of the
previously created NullFile.

Not that it is important to add support for this in the ipcd to support
AF_UNIX sockets, otherwise the socket() created in relibc won't be
associated with a address / path.

Update README.md to remove broken link.

Closes #1

See merge request !1

Opting to just remove the link altogether to fix #1

This reverts commit 438acd7d.

Apparently the test I wrote passes anyway with the old code.
I assume the kernel is filtering the events out.