[llvm] [offload][nfc] Extract libomptarget infrastructure into libompaccsupport (PR #213784)

[Jan André Reuter via llvm-commits]

================
@@ -5,18 +5,20 @@ if(NOT TARGET "omp")
 endif()
 
 add_library(omptarget SHARED
-  device.cpp
   interface.cpp
   omptarget.cpp
-  OffloadRTL.cpp
   LegacyAPI.cpp
-  PluginManager.cpp
-  DeviceImage.cpp
 
   OpenMP/API.cpp
-  OpenMP/Mapping.cpp
   OpenMP/InteropAPI.cpp
-  OpenMP/OMPT/Callback.cpp
+
+  ../libompaccsupport/device.cpp
+  ../libompaccsupport/PluginManager.cpp
+  ../libompaccsupport/DeviceImage.cpp
+  ../libompaccsupport/OffloadRTL.cpp
+
+  ../libompaccsupport/Mapping.cpp
+  ../libompaccsupport/OMPT/Callback.cpp
----------------
Thyre wrote:

I wouldn't reuse `OMPT/Callbacks.cpp` for OpenACC. The profiling interface of OpenACC is fundamentally different to OMPT.

For OpenACC, all callbacks have the following signature:
```c
typedef void (*acc_callback) (acc_callback_info*, acc_event_info*, acc_api_info*);
typedef acc_callback acc_prof_callback;
```
For OMPT, there are several different callbacks, all with their own signature.

If OpenACC re-uses the OpenMP Tools Interface, there's a good chance that invalid event sequences are dispatched to a tool, which can lead to unintended program behavior. I mentioned this in the [RFC](https://discourse.llvm.org/t/rfc-openacc-runtime-in-llvm-offload-libacctarget/90793/5?u=thyre).

Having a clean split between the OpenACC profiling interface and the OpenMP Tools Interface is probably better for maintainability.

https://github.com/llvm/llvm-project/pull/213784