Remove MemorySpace::[de]allocate overloads without labels

[masterleinad]

I noticed in #6794 (comment) that we call MemorySpace::deallocate without a label only from internal allocations where we can do better.
Thus, this pull request suggests streamlining the interface by removing all overloads for MemorySpace::[de]allocate that don't take a label and attempts to include labels KokkosTools events in allocate and deallocate. So far, I only made sure to provide labels for SYCL in all places that need them now.
This also mirrors better what we do for View allocations anyway, i.e., we force the user to provide a label when allocating. The label is passed implicitly when deallocating whereas here it is explicit (since we also don't store it in SharedAllocationRecord or the like).

[ldh4]

Should these [de]allocate functions go through a proper deprecation process? They are technically public functions in a non-impl namespace, available to be called in places external to kokkos.

[masterleinad]

Should these [de]allocate functions go through a proper deprecation process? They are technically public functions in a non-impl namespace, available to be called in places external to kokkos.

Yeah, that's up for debate. For me, they are implementation details but of course they could be used somewhere.

[ldh4]

Other than the need for a discussion for a potential deprecation, looks good to me.

[masterleinad]

Other than the need for a discussion for a potential deprecation, looks good to me.

Let me add a commit with the deprecations.

[dalg24]

Since when do we have these MemSpace::[de]allocate overload with a label vs the ones w/o a label?

What is problematic about having both?

Why is requiring a label the right thing to do?

[masterleinad]

Since when do we have these MemSpace::[de]allocate overload with a label vs the ones w/o a label?

The version with labels was introduced in #3084. The one without labels was the only overload before that.

What is problematic about having both?

There doesn't seem to be a good case where you cannot provide a meaningful label. We require a label for View allocations anyway. Not providing a label (possibly by accident, not knowing that the other overload existed) makes debugging [de]allocations events harder (provided the respective backend reports back to Tools events).

Why is requiring a label the right thing to do?

This pull request is motivated by #6794 (comment). It's very hard to understand Kokkos Tools output for allocation/deallocation events if the label is omitted. In that issue, we were trying to hunt down a specific deallocation that made a test introspecting Tools events fail (since there was an unexpected fence). With the changes in this pull request, we would have caught the offending deallocation directly.

[tcclevenger]

I like the change.

[crtrott]

I am blocking for now. I am not sure I agree with removing the allocate function without label. I am even less sure I agree with removing the deallocate function with label - since it means that a user has to track the label around somewhere. And what would it mean to provide a different label at deallocate than was used on allocate.

[ajpowelsnl]

@masterleinad , @crtrott -- on the agenda for discussion