Clarify or fix urInit and urTeardown behavior

[pbalcer]

During the discussion on #220, it was established that current global state initialization and destruction with the use of urInit and urTearDown are, at best poorly documented, and at worst, they might prevent the correct use of Unified Runtime in two independent modules in the same process.

The current documentation for urInit states that The application may call this function multiple times with different flags or environment variables enabled. and The implementation of this function must be thread-safe for scenarios where multiple libraries may initialize the adapter(s) simultaneously.. These two requirements can only be fulfilled together if the different flags or environment variables in all calls after the first one are entirely ignored. This might be misleading, especially if some library that uses UR doesn't take into account that it might be used in a process where UR is already initialized - this might be a relevant consideration for the design of the ONEAPI_DEVICE_SELECTOR (#220) feature or the loader config implementation (#681). In other words, software currently has no guarantees whether urInit does anything, but the documentation makes it seem as if it does.

The urTearDown function documentation doesn't specify whether it can be called multiple times. Current adapter implementations cannot. This creates a problem for scenarios where multiple libraries may initialize the adapter(s) simultaneously., because those libraries would require an external mechanism to coordinate calling urTearDown. This might not be practical.

In previous discussions, a proposal was made to create a separate reference-counted object on which urInit and urTearDown operate. In addition to helping clarify the global state lifetime, it would also address several other API issues as outlined in #220 (comment).

[pbalcer]

Addressed in #715, with a few small follow up changes in #728.