Interactive channel refactor

The goals of this work are:

* To fix issue where backgrounding and re-interacting with channels wasn't
  working.
* To fix issue where closing of meterpreter was not closing off background
  prcoesses (such as cmd.exe).

The two things preventing this stuff from working were:

* When interactive channels are backgrounded their handles were destroyed
  along with the context that wraps them up. Making them interactive again
  had no impact because the handle and context were invalid. If anything,
  this made meterpreter unstable. Sometimes the session would die when
  attempting to interact with the channel again.
* When closing channels, there was no way of terminating the process that
  sat behind the scenes because no reference to the process was retained.
  Channels would close and handles would close, but no process termination
  was done.

To fix these problems:

* The interactive thread no longer terminates when backgrounded. Instead
  its put in a suspended state where it's waiting a signal from a resume
  handle that's associated with the channel's context. This means that the
  destruction of the context doesn't happen at all until the termination
  of the channel, which is exactly when it should happen anyway.
* Process handles are stored alongside the input/output handles so that
  when the time comes, the process can be terminated if required. This
  means that when the channels are closed, the code has a reference to the
  associated process which can be terminated. This is only done for
  interactive processes, non-interactive processes do not have this
  problem because meterpreter doesn't have to keep track of them.
Fix up POSIX to match channel changes

POSIX was out of whack with Windows as a result of the changes made
around channels. The schedular in posix was very different, and this
commit brings it into line.

Other than the obvious issues, a non-obvious issue with the changes
was that the channel was being freed up on close prior to the thread
terminating. This doesn't appear to be an issue on Windows, but was
causing crashes on close in POSIX.

The changes go quite deep. This changeset requires a lot of testing.
Final Windows changes to match POSIX requirements

This changeset brings windows into line with the last set of POSIX
changes. With this changeset we are now in a position where both POSIX and
Windows are able to create and open interactive channels, put them in the
background, and terminate them without crashing, hanging or leaving
processes running behind the scenes.
Remove debug flag
Re-add closing of handles on destroy
Merge branch 'upstream/master' into channel_refactor_2

Conflicts:
	source/common/arch/posix/scheduler.c
	source/common/arch/win/scheduler.c
Fix POSIX crash on unsupported command and channel term

Crashes were occuring when the underlying channel had no more output
because the value of the `bytesRead` variable was not set to zero.
Consumers of the function assumed that bytesRead was value if non-zero.

POSIX would also hang when unsupported commands are executed, this
commit changes this so that a response is returned when the command
isn't supported.
Land #38, scheduler and channel refactor