Tiny little refactoring of DesktopEnvironment.

Making DesktopEnvironment a single interface that ClientSession needs to interact with the desktop (i.e. capture audio/video and inject input).

DesktopEnvironment is a single-threaded, synchronous interface. Implemenattions are free to use multithreaded/asynchronous backends as long as synchronous nature of the interface is preserved. For example such a backend should be able to shutdown without any assistance from the DesktopEnviroment's owner.

Specific changes:
  - AudioCapturer and VideoFrameCapturer are owned by AudioScheduler and VideoScheduler correspondingly.
  - Both AudioScheduler and VideoScheduler can now be stopped completely asynchronously.
  - Both AudioScheduler and VideoScheduler are owned by a specific DesktopEnviroment implementation.
  - AudioScheduler::SetEnabled() changed to Pause() to match the corresponding method provided by VideoScheduler.
  - ClientSession::Stop() is synchronous now.
  - MouseClampingFilter now gets the screen size from DesktopEnvironment::GetScreenSize() which does not try to access the cached screen size from a wrong thread.

BUG=104544, 134694

[alexeypa (please no reviews), 2013-01-03 20:47:18]

Rubber stamp, please. ;-)

[Wez, 2013-01-03 20:57:03]

On 2013/01/03 20:47:18, alexeypa wrote:
> Rubber stamp, please. ;-)

Yeah, right... :P

Aside from the hugeness, this looks like a good set of cleanups - thanks for
taking care of it!

There's a bug for DesktopEnvironment interface cleanup at crbug.com/104544,
which this CL should probably refer to as well.

[Wez, 2013-01-03 21:05:48]

I don't like the fact that this pushes the AudioScheduler and VideoScheduler
into each DesktopEnvironment implementation; the intent was that
DesktopEnvironment should become a factory for the desktop integration
components (audio & video capturer, event executor, etc).  What's your reasoning
for abandoning that approach?

[alexeypa (please no reviews), 2013-01-03 21:26:08]

On 2013/01/03 21:05:48, Wez wrote:
> I don't like the fact that this pushes the AudioScheduler and VideoScheduler
> into each DesktopEnvironment implementation; the intent was that
> DesktopEnvironment should become a factory for the desktop integration
> components (audio & video capturer, event executor, etc).  What's your
reasoning
> for abandoning that approach?

The problem is that in the IPC case the audio/video capturers and event executor
are owned by two parties each: ClientSession (or the corresponding scheduler) on
one side and the component handling the IPC I/O on the other side. In order to
manage them properly we would need to create two separate front-end interfaces
(used by ClientSession and the IPC component correspondingly) and a ref-counted
core, actually implementing the functionality and dealing with threading issues.

Packaging schedulers to the desktop environment implementation makes it much
easier. We can make assumptions about lifetime of the capturers, so they remain
simple plain objects.