More IO Changes (need feedback)

[Andrew Whitworth]

I've got three new branches that I've been playing with today to make
even more changes to the IO system. I'd like some feedback on these
changes before I do any more work on these. I haven't spent much time
on these yet, so if people don't like what they're doing I can abandon
ship without losing too much effort.

1) whiteknight/pipe_pmc This branch separates out File and Pipe logic
into two separate pmcs. FileHandle is for file IO only and a new Pipe
PMC is for pipes only. The mode format specifier "p" is no longer
valid and throws an exception in this branch. This is a breaking
change. The other branches I've worked on build on this foundation, so
if we don't like this we can forget about all of it.

2) whiteknight/io_vtable_lookup In Parrot master, we lookup
information about the IO_VTABLE and the read/write IO_BUFFERs using
VTABLE_get_pointer_keyed_int. This is a bad system. In this branch,
IO_VTABLE is looked up using a type map instead, so a FileHandle
always maps to the filehandle vtable, and a Pipe always maps to the
Pipe vtable (same for Socket, StringHandle, etc). This branch also
adds a new IOBuffer PMC which, while early in development, gives
direct access to IO buffer logic. IOBuffer PMCs are now stored as
named properties on the PMC (not attributes), which means they can be
looked up, attached, and used without any raw get_pointer/set_pointer
accesses.

3) whiteknight/io_userhandle This branch brings together the previous
ideas and makes the IO system fully polymorphic. In this branch you
can use ANY arbitrary PMC as a handle type for purposes of the IO
system, without needing to subclass from or delegate to a built-in
handle type. So long as your PMC implements a common set of methods,
you can use it for all IO operations.

Again, these branches are all very early in development. The
FileHandle/Pipe change is the only breaking change, everything else is
completely internal. If people like these ideas I can continue to work
on them and we can talk about timelines and an upgrade path to limit
breakages in NQP/Rakudo. If people don't like these things I can go
back to the drawing board.

Thanks,

--Andrew Whitworth