Separate exported variables by class hierarchy in the inspector.

[jonbonazza]

Describe the project you are working on:
Any project, but I think most useful for addons. That's just my opinion though.

Describe the problem or limitation you are having in your project:
I create a lot of addons that I either use in multiple projects internally or plan to release publically. These addons often include scripts and scenes that have multiple layers of inheritance, each with some number of variables exported to the inspector. Currently, all of the exported variables from all levels of inheritance created by scripts are merged and listed under a single inspector category called "Script Variables." For node hierarchies with a lot of exported variables this creates a lot of clutter in the inspector and makes it hard to quickly find the variable you want.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Exported variables from built-in nodes are separated in the inspector by class name. For instance, Node2D variables are listed under a separate category in the inspector than exported variables from CanvasItem, which in turn are under a separate category than those from Node. I think that variables exported via scripts should follow similarly.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
As an example, if I have a script class Creature that extends KinematicBody2D and then another script class called BattleCreature that extends Creature, the exported variables from BattleCreature should be listed in a separate category than those of Creature.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
There may be ways to better categorize exported variables individually, but I am not aware off any if so. If they do exist, it still would be more convenient if this was just done automatically and worked the same way as built-in nodes for consistency.
Is there a reason why this should be core and not an add-on in the asset library?:
It's likely going to require changes to the ClassDB and/or other core components.

[jonbonazza]

@Calinou I feel like this is probably a duplicate, but I can't seem to find another issue in the backlog.

[Xrayez]

Quite similar to #1255.

PROPERTY_USAGE_CATEGORY can be currently customized in 3.2, but that works only if you create properties via _get_property_list() in the first place, and of course you'd have to separate stuff manually.

[KoBeWi]

Duplicate of #109