[SYCL] Remove memory allocation/free nodes

[EwanC]

There are concerns with the currently specified approach so remove the API and advise users to allocate memory before submitting the graph. Marked as draft for now as this requires meeting discussion.

Conflicts with semantics of these PRs, which should be closed if we merge this:

• USM node clarifications and API generalization #66
• adding initial support for malloc/empty node #62

Addressed #39

[Bensuo]

LGTM, just a minor comment.

[sommerlukas]

As already discussed a bit over in the graph fusion proposal, the current proposal for graph fusion builds on top of add_malloc_device to specify internalization of pointers through a property.

Removing the add_malloc_device API from the graph proposal does not make internalization of USM pointers impossible, as the same property could be passed to the core USM functions malloc_device/malloc_shared, to mark a USM pointer for internalization (although this might slightly complicate the implementation).

However, attaching the property to add_malloc_device has two advantages over attaching it to malloc_device/malloc_shared:

• Granularity: When attaching the property to add_malloc_device, it is possible to limit the scope of the internalization semantics to just the graph. When attaching the same property to malloc_device/malloc_shared, the internalization semantics would apply to all graphs using this USM pointer. Of course, this can be avoided by allocating device memory just for the use in the graph by the user, but users would need to make sure to not accidentally use a pointer with internalization semantics in a graph where this is not intended.
• Optimization: When the internalization property is attached to add_malloc_device and the JIT compiler is successful in his attempt to internalize during graph::finalize, it is possible to completely remove the device allocation from the graph. This can reduce the number of device allocations, potentially leading to higher performance. If the USM allocation happens outside of the graph and the graph has no control over it, this optimization won't be possible.

tl;dr: Removing add_malloc_device will not make USM internalization in graph fusion impossible, but it may hinder some optimizations and require extra care from the user.

[reble]

LGTM. Some minor comments.

[EwanC]

Merging this, since although we're in the middle of considering other ideas of the memory allocation API, the existing API isn't one we currently want to promote, so removing it better represents the current status of the feature.

Once we have a concrete idea of the memory allocation API we want to advocate, then we can create a PR for that. Even reverting this commit from the git history, in the case it does turn out we want to bring back what we had.