Add support for CAS after FXAA about vkbasalt

[pchome]

If you do not plan to create a ultimate shader loading tool, then you could split the code to create two separate vulkan layers and one meta-layer file to load both of them.

Let's say VK_LAYER_VKBASALT_cas and VK_LAYER_VKBASALT_fxaa, which can be used separately and VK_LAYER_VKBASALT_fxaa_cas as meta-layer.

{
    "file_format_version" : "1.1.0",
    "layer" : {
        "name": "VK_LAYER_VKBASALT_fxaa_cas",
        "type": "GLOBAL",
        "api_version": "1.1.125",
        "implementation_version": "1",
        "description": "a post process layer",
        "component_layers": [
            "VK_LAYER_VKBASALT_fxaa",
            "VK_LAYER_VKBASALT_cas"
        ]
    }
}

Later, in case there will be TXAA (if it even possible), just add one more small vulkan layer and new meta-layer file for VK_LAYER_VKBASALT_txaa_cas.

Also, in this case you may want to use built-in shader data. E.g. generate C header file and use it during compilation.

$ glslangValidator -V fxaa.frag --vn fxaaShaderData -o fxaa.h

An environment variable for CAS configuration let you completely avoid user data directory dependency. In case of an explicit vulkan layer the launch command could look like

$ VK_INSTANCE_LAYERS=VK_LAYER_VKBASALT_fxaa_cas CAS="0.1" vkcube

Layers and directory structure examples: vkBasalt.zip
LD_LIBRARY_PATH="/path/to/lib64:/path/to/lib" and ~/.local/share/vulkan/ (or VK_LAYER_PATH=/path/to/layer/file) for local installation.

[DadSchoorse]

@pchome I have considered splitting the layer up, but this would be result in more memory fragmentation and adding new shaders would mean to many possible combination of those.