Geometry Nodes: Expose the active modifier to the UI

This exposes the operator to set the active modifier as the type icon
in the header of the modifier panels. Tweaks to the widget drawing
code were necessary to use the red alert for non-emboss operator
buttons. Then, the panel for the active modifier gets a border around it
(which currently uses the property search theme color), requiring
an "active property" field in the PanelType struct.

Geometry Nodes: Add an operator to set the active modifer

Also make new modifiers active, and properly set the active
state when duplicating a modifier.

Geometry Nodes: Disallow editing and animating modifier active property

There will be an operator to access this property instead, which provides
a better name and tooltip to expose in the UI, and makes it more clear
that the property is dependent on the other modifiers.

Geometry Nodes: Add the concept of an active modifier

This commit adds functions to set and get the object's active
modifier, which is stored as a flag in the ModifierData struct,
similar to constraints. This will be used to set the context in
the node editor. There are no visible changes in this commit.

Cleanup: use struct instead of class

Merge branch 'master' into geometry-nodes

Geometry Nodes: Categories for the nodes

See T82367. There is some ongoing discussion about Attributes vs
Attribute. But it is settle to Attribute, so it matches Color, Vector
and Geometry.

Geometry Nodes: T82701 Name for initial Node Groups

Rename it from "Geometry Node Group" to "Geometry Nodes". This is
shorter and equality descriptive.

Geometry Nodes - Internal rename + API change: NODES for anything but UI

Most of the times the nodes will be non-empty. Empty is really only what
shows in the UI.

Geometry Nodes: transform geometry in Object Info node

Geometry Nodes: give nodes access to object that is being modified

Geometry Nodes: simplify attributes api and support deletion

The main difference is that the functions to access attributes have
been moved to MeshComponent and PointCloudComponent.

Geometry Nodes: support controlling instance scale in point instancer node

Geometry Nodes: support point cloud component in random attribute node

Geometry Nodes: support rotation and scale in instances component

Geometry Nodes: fix memory leak

Geometry Nodes: initial Random Attribute node

This adds some ui boilerplate code for the Random Attribute node and
provides an initial implementation.

Note, while the implementation can already randomize attributes, it might
not behave as expected under all circumstances yet. It's still work in progress.

Geometry Nodes: use attribute api in point instance node

Geometry Nodes: use attribute api in point distribute node

Geometry Nodes: initial generic attribute access API

I will have to do a couple more iterations on this api in the upcoming weeks,
but for now it should be good enough.

The API adds an indirection for attribute access. That has the following benefits:
* Most code does not have to care about how an attribute is stored internally.
This is mainly necessary, because we have to deal with "legacy" attributes
such as vertex weights and attributes that are embedded into other structs
such as vertex positions.
* When reading from an attribute, we generally don't care what domain the
attribute is stored on. So we want to abstract away the interpolation that
that adapts attributes from one domain to another domain (this is not
actually implemented yet).

Accessing attributes through this indirection does have a performance penalty.
In later iterations of this API I want to reduce this penalty and extend the API
so that performance critical code does not have to go through the indirection
for every attribute access.

Other possible improvements for later iterations include:
* Actually implement interpolation between domains.
* Don't use inheritance for the different attribute types. A single class for read
access and one for write access might be enough, because we know all the ways
in which attributes are stored internally. We don't want more different internal
structures in the future. On the contrary, ideally we can consolidate the different
storage formats in the future to reduce the need for this indirection.
* Remove the need for heap allocations when creating attribute accessors.