Disk files are always opened in a blocking way because epoll (for
instance) will always say that a file is ready for reach or write. But
this is only for regular disk files, and that doesn't apply to pipes and
characters devices for example.

Opening `/dev/tty` (a character device) will block the current thread
when trying to read from it until you start typing on the keyboard.
IO::FileDescriptor was taking care to check the file type, but File
always told it to be blocking.

Worse, trying to open a fifo/pipe file will block the current thread
until another thread or process also opens it, which means that we must
determine whether to block _before_ trying to open a file (not change it
afterwards).

I also added a `blocking` parameter to `File.open` and `File.new`.

…thread

Removes the automatic detection of the file type and blocking behavior
before opening the file as we must support at least EINTR and ENXIO
return values for `open(2)`.

Blocking still defaults to true. Developers may pass nil for auto
detection or false to force the nonblocking flag (after open).

Opening a fifo without another thread/process also trying to open for
read or write will still block the current thread (will be another PR).

Starting threads very likely requires support from the interpreter to
create the thread (so it knows about it) to run the interpreted code in.

This also fixes the "can't resume running fiber" exceptions that started
appearing in the wait group pull request, because they were always run
after the thread related specs.