Clean up of the virtualization engine. about appstract HOT 4 CLOSED

First changes are already made in r303 and in the previous development of the 
registry virtualization engine.

What started as a simple clean up has now grown to a complete rework.
This rework must result in a flexible, consistent and maintainable system
in which all engine components are completely encapsulated.


r334    Rework of AppStract.Server.Hooking namespace - Phase 1

In this revision multiple important changes were made:
- Added the HookProvider type, and it's derived classes
- Added the HookHandler type, and it's derived classes
The old HookManager is completely reworked to support these types.
It's possible to register multiple HookProviders to HookManager, while each of 
those HookProviders contains a (private) HookHandler class.
In essence, a HookProvider provides API hooks by providing the needed 
delegates, and the needed handler methods (HookHandler).
Currently only two HookProviders are declared:
- FileSystemHookProvider (makes use of an IFileSystemProvider in it's 
HookHandler class)
- RegistryHookProvider (makes use of an IRegistryProvider in it's HookHandler 
class)
In a later stage more providers can easily be added, for example: 
ProcessHookProvider (CreateProcess function), CLRHookProvider (hooking basic 
CLR functions), NetworkHookProvider (hooking network functions), ...


r336    Rework of AppStract.Server.Hooking namespace - Phase 2
    - Added the VirtualizationEngine class.
    - Added the AppStract.Server.Engine namespace and moved some other namespaces around.

The VirtualizationEngine class is responsible for managing the complete 
virtualization engine (previously the engine was somehow managed in GuestCore). 
Currently it's not possible to shut the engine down, although this 
functionality can easily be implemented if the need would ever arise.
Also, the namespaces have been reorganized. For types outside of the 
AppStract.Server.Engine namespace only the VirtualizationEngine type should be 
important, since all other types are managed by it.

Closing this issue, a lot has changed since august.

The engine is now well implemented, except for the initialization logics (but 
for this another issue will be created)

Marked as fixed