Add webcam thread to avoid COM-related crash

Webcam code was sometimes causing crashes in Meterpreter when attempting
to stop the camera after a frame had been captured. This appeared to be
because the thread that started the capture was not the same thread that
ended it.

CoInitialize() and CoUninitialize() need to be called on the same thread
and objects created on one thread need to be released on the same thread.
This change results in a new worker thread that is used for the lifetime
of the capture, and the callers have to interact with this thread via
basic threading events.

This is currently "proof of concept" code, rather than production-ready
code. The goal is to see if it solves the issue on the known targets
before tidying it up and locking it down for release.
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 'master' into webcam_crash_fix
Clean, tidy and add documentation

This commit tidies up the webcam code, adds documentation and adds a
couple of small clean-ups and optimisations around resource usage.

`audio.h` is not included in `webcam.h` any more as it's not needed at all
by that code, however it has been added to `precomp.h` so that `stdapi.c`
can use and see it along with the other files.
Docs for list, xor and remote
Merge branch 'upstream/master' into channel_refactor_2

Conflicts:
	source/common/arch/posix/scheduler.c
	source/common/arch/win/scheduler.c
Merge branch 'master' into webcam_crash_fix
Fix call to thread_create
Fix double-free issue resulting crash

Note: webcam stuff doesn't work on Windows 2012. Work needs to be done to
make it work on this platform because the DX classes used to do the webcam
capture are not present on the system.
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
Land #44, fix webcam crashes
Land, #47 doc updates