COMP: Fix deprecated-copy-with-dtor via rule of zero + rule of five (cf. #6538)

[hjmjohnson]

Silences all -Wdeprecated-copy-with-dtor warnings on five Core/Common classes, choosing the fix per class kind: rule of zero for the value/leaf types, rule of five for the polymorphic bases. Compare with #6538 (rule of five for all five).

Class	Kind	Fix here
DefaultVectorPixelAccessor	value	remove ~=default (rule of zero)
MinPriorityQueueElementWrapper	leaf (inherits virtual dtor)	remove ~=default (rule of zero)
MaxPriorityQueueElementWrapper	leaf	remove ~=default (rule of zero)
ElementWrapperInterface	polymorphic base	keep virtual ~=default + ITK_DEFAULT_COPY_AND_MOVE
ElementWrapperPointerInterface	polymorphic base	keep virtual ~=default + ITK_DEFAULT_COPY_AND_MOVE

Why the two treatments

ElementWrapperInterface/ElementWrapperPointerInterface are documented public extension points ("you can use this wrapper … it follows the ElementWrapperInterface and thus can be used in the queue") with virtual members. Removing their virtual destructor would break delete through ElementWrapperInterface* for downstream custom wrappers (C++ Core Guideline C.35) — so those keep the virtual destructor and get ITK_DEFAULT_COPY_AND_MOVE (same as #6538). The three value/leaf classes are never a polymorphic-delete base, so rule of zero is safe and lighter.

This split was prompted by a Greptile P1 on an earlier revision that removed the interface virtual destructors; see the resolved thread.

Warnings fixed (CDash build 11383687, Mac14.x-AppleClang-dbg)

Fixes all 33 ITK-proper -Wdeprecated-copy-with-dtor warnings (28 DefaultVectorPixelAccessor, 4 Min, 2 ElementWrapperInterface, 1 Max). The only 2 remaining of this type are ThirdParty/GDCM/gdcmFile.h (vendored upstream), which #6538 also excludes.

Local validation

• Instantiation harness over all five templates (forced full instantiation) + queue push/pop + copy/move → compiles and runs clean.
• Polymorphic-destruction check: delete of a custom wrapper through ElementWrapperInterface* runs the derived destructor (count = 1).
• pre-commit run --all-files clean.

Relative to #6538: identical on the two interfaces (virtual dtor + ITK_DEFAULT_COPY_AND_MOVE), differs only on the three value/leaf classes (rule of zero vs the macro). The two PRs touch the same lines, so only one should merge. Follows #6664 (rule of zero for LogicOpBase) and #5849 (rule of zero for NthElementPixelAccessor).

[hjmjohnson]

Related work — this continues an established rule-of-zero campaign

This PR isn't a one-off: it's the next step in a consistent, already-merged effort to clear the -Wdeprecated-copy-with-*-dtor warnings by removing redundant special members (rule of zero) rather than declaring them. That context is the strongest argument for preferring this over the macro approach in #6538.

Timeline

PR	Merged	What it did
#6430	2026-06-11	Removed -Wno-deprecated from ITK's warning flags — the root cause: it un-suppressed these -Wdeprecated-copy-with-dtor warnings so they now show on CDash.
#5849	2026-03-03	Rule of zero for NthElementPixelAccessor — a pixel accessor, directly analogous to DefaultVectorPixelAccessor in this PR.
#6592	2026-07-14	Rule of zero for functors with user-declared destructors (~MaskInput, ~SimilarPixelsFunctor, …).
#6664	2026-07-20	Rule of zero for LogicOpBase.
this PR	—	Rule of zero for DefaultVectorPixelAccessor + the priority-queue wrapper/interface classes (the remaining CDash offenders).

The 2024 ITK_DEFAULT_COPY_AND_MOVE series (#4652, #4639, #4627, #4626, #4725) established the rule-of-five macro that #6538 uses. The 2026 campaign above has consistently chosen the rule-of-zero direction instead, which is what this PR follows.

Net: #6538 and this PR fix the same 33 warnings; merging this one keeps the codebase aligned with the #5849 / #6592 / #6664 precedent (less code, no macro). Only one of the two is needed.