Generalize ur_usm_pool_limits_desc_t

Currently, ur_usm_pool_limits_desc_t exposes parameters similar to the ones exposed by SYCL_PI_LEVEL_ZERO_USM_ALLOCATOR .

There are a few problems with existing params:

1. capacity is tricky to use: it describes a number of allocations and does not take into account allocation size. Also, UR does not expose any statistics that could be used to tweak the capacity. Moreover, it might not be applicable to all heap managers.

   I propose removing this parameter.

2. maxPoolSize might be ambiguous. Unified Runtime can create multiple 'sub-pools' - it can decide to create pool per each device or to create a pool that spans multiple devices in certain cases. Having the same pool size limit for both of those cases will not be optimal.

   We could replace the maxPoolSize with a decay parameter that, instead of specifying limits in terms of space, defines it in terms of time - for how long the pool is allowed to keep memory pages around, similar to: https://jemalloc.net/jemalloc.3.html#arenas.dirty_decay_ms

Related discussion: https://github.com/oneapi-src/unified-runtime/pull/324

Start with the ur_usm_pool_limits_desc_t definition and the related discussion in PR #324; compare the existing capacity and maxPoolSize parameters with the proposed decay semantics and the linked jemalloc reference. Done means the parameter design and behavior are agreed and reflected in the Unified Runtime API.