Cannot extend the base Texture class via script

[Xrayez]

Godot version:
3.2.2-stable

OS/device including version:
Windows 10

Issue description:
Impossible to create a new instance of a custom texture implemented via script which inherits Texture:

extends Texture
class_name CustomTexture

Extending ImageTexture works in contrast:

extends ImageTexture
class_name CustomImageTexture

Steps to reproduce:

1. Create a global script to just extend Texture.
2. Create a Sprite and try to assign a new custom texture from the inspector.

Workaround:
Extend ImageTexture instead. The reason for extending from Texture directly is to achieve better efficiency and flexibility by using the VisualServer API directly. This is possible to do via C++ but seems like not possible in GDScript, so this caught be off guard.

Not every texture is based on an image, as it can be procedurally generated (like NoiseTexture), so using ImageTexture is not a perfect option for this.

If that's expected, than perhaps that's documentation issue. From the Texture description:

Texture is a base for other resources. It cannot be used directly.

Perhaps this is what directly means here, so needs clarification.

That said, I'm not sure whether it's really possible to extend Texture via script in the first place, because I see no virtual methods.

Minimal reproduction project:
texture_base_extend.zip

[Xrayez]

The issue with suggested workaround is also not usable in practice (extending ImageTexture), I've just tested this.

Look at https://github.com/Maujoe/godot-custom-gradient-texture for concrete use case, which aims to replicate the functionality proposed in #31655. The plugin doesn't connect the gradient changed signal, but even if you do, then it's very difficult to update the texture by modifying the gradient directly from within the inspector (no way to drag the gradient sliders). I suspect the issue is with ImageTexture.create_from_image(), which somehow forces the inspector to update itself immediately, losing focus?

[KoBeWi]

If there's no intention in fixing this, we should at least make the editor show a proper error. See #46073