WinRT capture support

WinRT capture support: Add support for WinRT in the MF capture framework by removing the disallowed calls to enumerate devices and create a sample grabber sink and adding framework for the MediaCapture interface and a custom sink which interfaces with the sample grabber callback interface

Notes:
Must make declaration for web camera in manifest and give permission when pop up arrives.

Any suggestions relating to how to make for a clean asynchronous shutdown are welcome.  Instructions on declaring the activatable sink object in the manifest are needed to use it instead of creating it manually as it leads to a better outcome internally as currently the MediaCapture must be recreated due to the way Microsoft designed the library unless using an activation ID which requires manifest declaration and export. It works though and all discussion issues are resolved (I supposed larger chunks of code could be conditionally compiled in C++/CX).  If using highgui as a DLL, then modifications would need to be made so there is the appropriate exports especially GetClassFactory.

Closing is dangerous as it cannot be done synchronously but the library is not designed for such asynchronous only design circumstance and would need some sort of isClosed or callback function or asynchronous task returned type of way. Using native C++ we can synchronize it but as C++/CX task library will throw an error calling this "illegal" it is a safe bet we should follow the Microsoft standards of what is "legal".

Support for the custom sink is extended to non-WinRT not for compatibility as Windows Vista client is a minimum regardless, but because it offers more flexibility, could be faster and is able to be used as an optionally different code path during sink creation based on a future configuration parameter.

HAVE_CONCURRENCY is ignored and tasks are used regardless as in WinRT it is safe to guarantee the parallel tasks library should be present as part of Visual Studio 2012/3 and without it would require a deal of wrapper code to implement create_thread, event objects or even using interlocked calls which might delve into the HAVE_WIN32 stuff.  The WinRT way is to use the task library.

It looks like C++/CX cannot be used for the IMediaExtension sink (which should not be a problem) as using COM objects requires WRL and though deriving from IMediaExtension can be done, there is little purpose without COM. Objects from C++/CX can be swapped to interact with objects from native C++ as Inspectable* can reinterpret_cast to the ref object IInspectable^ and vice-versa. A solution to the COM class with C++/CX would be great so we could have dual support.