Reducing complexity in child_proces

**This will properly result in some discussion, please do not make it a vote war!"**

The complexity of the `child_process` module has increased a lot lately, especially since `thread` (internally called `isolate`) support. In `node 0.7` we currently have between 8 and 6 ways of spawning a child. And there is no significant difference between them.

| **Method** | **Process** | **Thread** |
|:-----------|:------------|:-----------|
| spawn      | yep         | yep        |
| execFile   | yep         | properly   |
| exec       | yep         | properly   |
| fork       | yep         | yep        |

This patch is an almost complete rewrite of the existing `child_process` module, but it do aim to add or change an API since `node 0.6`. The complexity is reduces by grouping the different methods the following way:

```
                 Child
             +-----|------------+
          Process             Thread
             |                  |
  +----------+--------+     ----+----
  |          |        |         |
spawn -> execFile -> exec      fork       
```

By thinking this it makes the purpose of the different methods more logical, not only us in the core but also the userland.

For instance there has previously been an discussion about having `stdout` and `stderr` in `.fork` however this would be really difficult since `threads` do not support so. But by adding a `silent` option to `.fork` this streams would exist anyway. _Please note that the `silent` option is a part of `node 0.7`._

###compatibility:

The compatibility is intended to total backward compatible. The only exceptions seams to be:

* **customFds:** this could be added to `Process` function but since this was marked as deprecated it was not added. We could eventually add a `share` option there would share the file descriptors with the parent, the option would then default to `[false, false, false]`.

* **pid:** When using fork there is no `pid` since this is no longer a process. This should not be a big deal since userland would kill the process with `fork().kill()` and do not have any other usage for this.

It should be noted that to secure some fallback in backward compatible a `channel` option is added to `.spawn`. This is a two way `buffer channel` there use the `stdin`, like the `JSON-IPC` there exist in `.fork`. But is much more low-level encourage userland to use `.fork` then they only need a node worker.

To make this more clear please consider to alias `.fork` to `.worker`.

Also `stdinStream`, `stdoutStream` and `stderrStream` will no longer be added to the userland `options` argument. _This properties was internal API only._

###Why a rewrite:

A rewrite seamed necessary since there was a lot of edge case preventing code there no longer was required because of the simplification of the object inherits flow. Most significant was that the `stdinStream` no longer needed to be a part of the `options` since this only needed to be handed in the c++ land.

Please also note that `stdout` and `stderr` channel detection is now done when `_internal.onexit` is executed, this way we do not pollute user land with `_closesNeeded` and `_closesGot`.

###remaining:

* The `.fork` do not support `sendHandle` yet, the code will of course be added to this pull request when supported in `c++ land`.
* The missing `.kill` support has been added to in this patch. However the support is not perfect since `.signalCode` and `.exitCode` is not set.