Refactor ShaderProfile to allow for pipeline extensibility

[tomspilman]

This PR is the first baby step towards making the content pipeline more easily extendable for new platforms.

Here I refactored the existing enum ShaderProfile into a class that knows how to perform various platform specific steps of the effect compiling process.

This also introduces a helper class LoadedTypeCollection<T> which scans loaded assemblies for types of a particular base class. We use this to gather the different instances of ShaderProfile which in the future could live in different pipeline extension assemblies.

This same technique will be applied to audio and texture processing next.

[tomspilman]

@KonajuGames @dellis1972 - Let's be sure to squash merge this one.

[tomspilman]

The unit tests for shader compiling all passed which is good. Want @dellis1972 to at least take a look at it first, but we should look to merge this soon.

[dellis1972]

@tomspilman looks ok. Any chance you can give a basic example of how to extend for a new platform? Just for reference. i.e what files need to be added etc.

[tomspilman]

@dellis1972

Any chance you can give a basic example of how to extend for a new platform?

Sure. This same technique will be used for all the hardware specific conversions... shaders, textures, audio.

In the case of shaders you just need to create one new class that derives from ShaderProfile:

class NewPlatformShaderProfile : ShaderProfile
{
    public NewPlatformShaderProfile() 
        : base("PlatformName", 123)
    {
    }

    internal override void AddMacros(Dictionary<string, string> macros)
    {
        // Sometimes you want to add shader macros that
        // let the shader author make changes based on platforms.
    }

    internal override void ValidateShaderModels(PassInfo pass)
    {
        // This lets you validate that the shader model in the 
        // pass information is valid for this platform.
    }

    internal override ShaderData CreateShader(ShaderInfo shaderInfo, string shaderFunction, string shaderProfile, bool isVertexShader, EffectObject effect, ref string errorsAndWarnings)
    {
        // This actually does the compiling of the shader returning a new ShaderData.
    }

    internal override bool Supports(string platform)
    {
        if (platform == "MyPlatform")
            return true;

        return false;
    }
}

The same sort of technique will be used for texture processing:

class MyNewPlatformTextureProfile : TextureProfile
{
    public override bool Supports(TargetPlatform platform)
    {
        if (platform == TargetPlatform.MyNewPlatform)
            return true;

        return false;
    }

    public override void Requirements(ContentProcessorContext context, TextureProcessorOutputFormat format, out bool requiresPowerOfTwo, out bool requiresSquare)
    {
        // TODO: Let the caller know if the texture processed with the specified
        // texture format will require power-of-two and/or square sizing.
        //
        // This is called from texture packing code like with fonts.
    }

    protected override void PlatformCompressTexture(ContentProcessorContext context, TextureContent content, TextureProcessorOutputFormat format, bool generateMipmaps, bool sharpAlpha)
    {
        // TODO: Do the actual compression of the content based
        // on platform requirements.
    }
}

That is it... the system will pick up the new profile and query it when trying to convert textures/shaders/audio for the new platform (or platforms) it supports.

You can see how just adding a new instance of a class is a much easier extension system than having to modify TextureProcessor, GraphicsUtils, SoundEffectProcessor, etc to add a new platform. It also allows for us to eventually place platform specific content processing into its own extension assembly.

[dellis1972]

@tomspilman thanks looks like a good change to me.
@KonajuGames shall I merge or you :P

[KonajuGames]

Merging.