Separate visual shader code out of shader editor plugin and dialog

[aaronfranke]

Last cleanup PR before actually moving visual shaders to a module: #64596

This PR moves the language-specific code out of ShaderCreateDialog. Its API of config has been changed to work with Strings for the type, instead of a hard-coded index. A small number of remaining hacks, such as things only working for text shaders, are indicated as comments - but not that these caveats were already present in the existing code, unmarked.

The language-specific code now lives in classes that derive EditorShaderLanguagePlugin. The TextShaderLanguagePlugin class provides editor integration for text shaders, and the VisualShaderLanguagePlugin class provides editor integration for visual shaders.

The base EditorShaderLanguagePlugin itself has static functions for registering shader languages in the editor (not to be confused with the non-editor code). Registered languages are consumed by ShaderCreateDialog and ShaderEditorPlugin, for populating the create dialog, and editing existing shaders, respectively.

The primary motivation behind this abstraction is to allow moving visual shaders to a module. However, this also allows for users to register new shader types in the editor. The API for doing this is not exposed, so it is not available for GDScript or GDExtension, but it can be used with modules. We should not lock ourselves in to any particular API for registering shader types unless we have a good use case first, therefore I intentionally kept this unexposed.

The exposed functionality from the user's perspective should be the same, except that the dialog's list of types now has the order "Shader, ShaderInclude, VisualShader" instead of "Shader, VisualShader, ShaderInclude", which makes sense because it groups the text-based ones together. This PR doesn't try to expand functionality, for example, shader templates are text-shader-only the same as it is in master.