Fix "use after scope" reported by ASAN

The float array is declared inside a smaller scope, pointed to, and then
used later. This simply moves the declaration outside of the if statement.
Also remove two redundant lines.

Cleanup and improve comments

Remove special handling of normals from point distribution

Refactor the "normal" attribute reading and writing

Merge branch 'master' into temp-geometry-nodes-normal-attribute

Merge branch 'blender-v2.92-release'

Fix: Mouse presses in some areas do not set active modifier

There are a couple of operations that are meant to set the active
modifier that currently don't. The first is a mouse press on the drag
icon on the right of the header, and the second is mouse presses on
modifier sub-panels headers.

This was an oversight in the implementation, especially the second,
because the blank space on the right of a sub-panel header often looks
just like the blank space elsewhere on the modifier's panel that
*does* set the active modifier.

Note that this purposefully doesn't include collapsing and expanding
the modifier as operations that set the active, since regardless of
whether that makes sense, it wasn't in the agreed upon design, which
would ideally not need changing for 2.92.

Differential Revision: https://developer.blender.org/D10155

Test derived normals write attribute

Merge branch 'master' into temp-geometry-nodes-normal-attribute

Geometry Nodes: Support the "normal" attribute

The `normal` attribute is a bit special for a few reasons:
- It has the special CD_NORMAL custom data type even though
it is just a float3.
- It is sometimes stored in the `MVert` array as a vector of
shorts instead of in a separate custom data layer.
- The custom data layer does not have a default name, so we
can't count on addressing it by name.
- It can exist on multiple domains, meaning that polys, vertices,
and corners can all have the "normal" attribute.

All of these combined raise a lot of questions about how to properly
support reading and writing from this attribute. The whole idea that
it should be valid to address an attribute with the same name on
multiple domains is challenging for the attribute code.

This branch currently supports reading normals stored in the `MVert`
layer and in `CD_NORMAL` layers. I'm not at all sure that this is the
ideal way of dealing with this situation, but it's a start.