Add support for native fd in Parrot.

This change allows tracees to have native file descriptors, which are not
intercepted/interpreted by Parrot in any way. This currently allows sockets and
pipes to be treated natively, as well as ttys already attached when Parrot
bootstraps the root tracee.

Various things to note about this commit:

o select/poll are now executed in the kernel without any interpretation by Parrot.
  This is accomplished by having a dummy unique open file (which maps to a pfs_pointer)
  for each file descriptor opened in Parrot (e.g. /chirp/host:port/foo). select/poll on
  a regular file always sets read/write/error status which is what we want.

o Before considering recvmsg/sendmsg, I had used a dummy "null" file descriptor
  (/dev/null) for open Parrot file descriptors. This was duplicated via dup2 to
  the desired fd. So if we opened /chirp/host:port/foo and set it to fd 3, we
  would have the tracee run dup2(<null fd shared for all tracees>, 3).

  Because of recvmsg/sendmsg being capable of sending a file descriptor to
  another process (which is fairly common), we need to "track" a Parrot fd that
  is sent to another tracee (we ignore a Parrot fd being sent to a process not
  being traced by Parrot, which at worst may break the application; we have
  never accounted for this possibility). We accomplish tracking an fd sent to
  another tracee by having the tracee create a file in the pfs_temp_dir,
  obtaining the inode, and then unlinking the file. Using this inode, we can
  identify a Parrot file descriptor received via recvmsg by doing stat on

      /proc/<pid of tracee doing recvmsg>/fd/<fd received>

  For sendmsg we need to increase the reference count for any Parrot file "in
  flight". There are important considerations though, from the comments for
  sendmsg in this commit:

    /* There is a situation where a process sends a file descriptor and the
     * receiver "discards" it unknowingly by doing a read instead of
     * recvmsg. We can't account for that since the kernel completely hides
     * that from us. So, it's possible an in-flight Parrot file descriptor
     * causes a reference increase on a file pointer but never a decrease.
     * It's also possible that a Parrot fd is sent to a process that is not
     * a tracee. Not only can we not see the recvmsg and decrement the file
     * pointer counter but that process receives a garbage "Parrot file"
     * too.
     */

o All socket/pipe operations fallthrough to the kernel. Sockets and pipes are
  always native.

o For open and openat (when path is absolute), if the file refers to a
  character or block device, we allow the open natively. This means a tracee
  can open/create its own terminals without inteference from Parrot.

o pfs_poll.* and all tracee wait states are obsolete and removed.

o When bootstrapping the root tracee, all regular files and directories
  that are inherited will be opened as Parrot files (as usual). The root tracee
  has to do some work before being attached by Parrot to open the unique Parrot
  files.

Fixes #48.
Maybe will fix (but does not currently) #346.