This PR introduces new debug macros that allow a more fined control of
which debug message to output and introduce C++ stream style for debug
messages.

Changing existing messages (except a few that I changed for testing)
will come in subsequent PRs.

I also think that we should make debug enabling OpenMP agnostic but, for
now, I prioritized maintaing the current libomptarget behavior for now,
and we might need more changes further down the line as we we decouple
libomptarget.

Reverts llvm/llvm-project#164392 due to fortran issues

Use the implementation in libomptarget. If libomptarget is not
available, always return the UID / device number of the host / the
initial device.

Follow-up from #162652

---------

Co-authored-by: Michael Klemm <michael.klemm@amd.com>

Adds omp_target_is_accessible routine.
Refactors common code from omp_target_is_present to work for both
routines.

---------

Co-authored-by: Shilei Tian <i@tianshilei.me>

On Windows, for a reason I don't fully understand boolean bits get extra
padding (even when asking for packed structures) in the structures that
messes the offsets between the compiler and the runtime.

Also, "weak" works differently on Windows than Linux (i.e., the "local"
routine has preference) which causes it to crash as we don't really have
an alternate implementation of __kmpc_omp_wait_deps. Given this, it
doesn't make sense to mark it as "weak" for Linux either.

This implements two pieces to restore the interop functionality (that I
broke) when the 6.0 interfaces were added:

* A set of wrappers that support the old interfaces on top of the new
ones
* The same level of interop support for the CUDA amd AMD plugins

`PRIVATE | ATTACH` maps can be used to represent firstprivate pointers
that should be initialized by doing doing the pointee's device address,
if its lookup succeeds, or retain the original host pointee's address
otherwise.

With this, for a test like the following:

  ```f90
  integer, pointer :: p(:)
  !$omp target map(p(1))
  ... print*, p(1)
  !$omp end target
  ```

The codegen can look like:
  ```llvm
   ; maps for p:
   ; &p(1),       &p(1), sizeof(p(1)),       TO|FROM              //(1)
   ; &ref_ptr(p), &p(1), sizeof(ref_ptr(p)), ATTACH               //(2)
   ; &ref_ptr(p), &p(1), sizeof(ref_ptr(p)), PRIVATE|ATTACH|PARAM //(3)
   call... @__omp_outlined...(ptr %ref_ptr_of_p)
  ```

* `(1)` maps the pointee `p(1)`.
* `(2)` attaches it to the (previously) mapped `ref_ptr(p)`, if present.
  It can be controlled via OpenMP 6.1's `attach(auto/always/never)`
  map-type modifiers.
* `(3)` privatizes and initializes the local `ref_ptr(p)`, which gets
passed
  in as the kernel argument `%ref_ptr_of_p`. Can be skipped if p is not
  referenced directly within the region.

While similar mapping can be used for C/C++, it's more important/useful
for Fortran as we can avoid creating another argument for passing the
descriptor, and use that to initialize the private copy in the body of
the kernel.

Summary:
This exposes the 'isDeviceCompatible' routine for checking if a binary
*can* be loaded. This is useful if people don't want to consume errors
everywhere when figuring out which image to put to what device.

I don't know if this is a good name, I was thining like `olIsCompatible`
or whatever. Let me know what you think.

Long term I'd like to be able to do something similar to what OpenMP
does where we can conditionally only initialize devices if we need them.
That's going to be support needed if we want this to be more
generic.