Migrate delete_array and delete_fragments from StorageManager to Array.

[bekadavis9]

Migrate Array APIs out of StorageManager: delete_array and delete_fragments. Note: this migration required addition of new, static versions of these internal APIs on class Array, which effectively do exactly what the versions in StorageManager were previously doing. This allows for a "hierarchical-like" structure among the inter-dependent APIs delete_group, delete_array, and delete_fragments.

---

[sc-23372]
[sc-47161]
[sc-47162]

---

TYPE: IMPROVEMENT
DESC: Migrate Array APIs out of StorageManager: delete_array and delete_fragments.

[ypatia]

FYI, the REST-CI failure should go away if you rebase to latest dev , it's due to sc-44928

[eric-hughes-tiledb]

This PR highlights a pre-existing problem with the way deletion is handled, but makes the problem worse. The symptom of the problem is the overloading of the names delete_array and delete_fragments. There are four functions in total; each name is both a member function and a static function. There are two aspects to the problem:

1. Insofar as underlying behavior goes, there's no good clarity to what the underlying operation is, how the remote operation is handled, and dispatch between the two. Those changes are beyond the scope of this PR. Such changes would require a rewrite.
2. Insofar as understanding the behavior goes, it's quite confusing as to what functions do what etc. This is primarily a documentation problem and is definitely within the scope of this PR.

We need better documentation for each of the four delete_* functions affected. Three are new; one was already present (member delete_fragments). Each of the functions needs to describe what it does in what circumstances and distinguish itself from its partner.

In the long term we need a coherently design for these capabilities; that time is not during this PR. Yet we will need to write such a thing in the future, and we need better documentation now so that future effort will have at least a signpost about what direction to head.

[eric-hughes-tiledb]

The documentation is still inadequate to address the basic confusion I had in first reviewing this PR.

• Why are there both static and member functions with the same name?
• What's the difference?
• When to use one instead of the other?

I'm not sure it's within the scope of this PR to find good answers for these, but at the very least we need to acknowledge the confusion.

Looking at the actual code, this much is clear. None of these functions seem to have the right signature. There's code in the C API interface functions that belongs in these functions, and vice-versa.

At minimum, we should do all these:

• Mark these functions inside of @section Maturity as interim versions awaiting a rewrite.
• Pairs of functions should reference each other.
• Mention that the static functions are a direct legacy of StorageManager.

Please do not confine the documentation to the bare minimum.

[eric-hughes-tiledb]

LGTM