[SYCL][Graph] Add get_id() public member function to modifiable command graph

[mmichel11]

• Follow-up to [SYCL][Graph] Add get_id() public method for graph #22194 with native recording support.
• Adds monotonically increasing graph IDs per process. Graph ID uniqueness is guaranteed in an application for the set of graphs using native recording and additionally for the set of graphs not using native recording. The application is required to differentiate if they intermix backends and require uniqueness.
• For native recording backends, IDs are fetched from the native API. If graph ID support is not present, then a fallback to a SYCL graph internal counter is used.

[mmichel11]

For the case where the application intermixes command buffer and native graphs, the command buffer IDs will increase monotonically (satisfying the spec) but not necessarily by increments of 1. This is because MID is still used for hashing by both native graphs and command buffer and will increment when either graph type is created.

@adamfidel If this is undesirable and we want command buffer IDs to increment by 1 for this case, then I think we can add a separate counter for the public facing ID.

[adamfidel]

I think this behavior is fine for a few reasons:

1. In the spec, it says "IDs increase monotonically as graph objects are created." Because we do not state that IDs increase monotonically when graph objects of the same recording type are created, then I believe this behavior is spec-compliant according to the proposal.
2. We already provided caveats if the user decides to mix graphs of various recording types
3. We anticipate that this use case of mixing native graphs with non-native graphs in the same application would be rare

So I think this implementation is fine as is.

[KseniyaTikhomirova]

@adamfidel since you expect it to be spec complaint, would it be better to extend spec with the clarification that granularity of monotonical increase for mixed cases are implementation-defined?

[mmichel11]

A monotonically increasing function has no guarantees regarding the amount of increase, but I agree it may be good to clarify it for users less familiar with the term. I added a sentence describing this.

L0 native graph also has instances where the ID increase is not 1 when graph fork-join occurs. It is good to make sure this is highlighted so users do not try to use it as a vector index for instance.

[adamfidel]

LGTM!

[mmichel11]

@KseniyaTikhomirova @intel/llvm-reviewers-runtime Could you please take a look at this PR?

CI failures are unrelated:

• Graph/Update/RecordReplay/whole_update_host_task.cpp is flaky and failing in other branches. Will disable this separately.
• bindless_images/dx11_interop/read_write_unsampled.cpp and Regression/multi_thread_enqueue_discarded.cpp are unrelated tests.

[KseniyaTikhomirova]

LGTM, just a couple of nits

[mmichel11]

@intel/llvm-gatekeepers Please consider merging.