Rename VariantZeroAssigner to VariantDefaultInitializer

[aaronfranke]

Discussed on RocketChat. VariantZeroAssigner's name indicates that it should assign zero, but it actually assigns the default value. For some types, such as Basis, Transforms, Color, Quat, the default value is non-zero. The new name VariantDefaultInitializer was suggested by @akien-mga.

[TokageItLab]

I am wondering if this PR will make Variant::zero() obsolete. To begin with, there are few parts that use Variant::zero(), and it is only needed for blending ValueTracks in AnimationTree. So if this PR is approved, perhaps the right way to go would be to obsolete Variant::zero() and implement AnimationTree::set_variant_to_zero() as a local function of AnimationTree.
Context: #59474 and #59490

[akien-mga]

If this is approved, then zero should also be renamed everywhere. But let's see what @reduz thinks first.

[akien-mga]

Discussed in PR review meeting, @reduz (and maybe @vnen) need to check a bit deeper why this is needed and why it doesn't reset all types of Variants (e.g. String, Callable).

[Iniquitatis]

Don't know how much of a compatibility breakage it will cause (if any), but can the zero method be renamed accordingly? IIRC, default is a reserved keyword, so what about default_value, for example?
As of now, it looks a bit weird that DefaultInitializer implenents the zero method, which doesn't zero out a value in all cases.

[vnen]

The change makes sense to me. Since it's an internal change it won't break compatibility. I do agree that the zero() methods should also be renamed.

[AThousandShips]

I'd just call it init, it is an Initializer and the other Initializers call it that

[YuriSizov]

Thanks!