0.15.2-staging

Adding set_function_entry to brige API (#5155)

Adds an optional `set_function_table` entry point to the realtime bridge
provider interface and bumps `CUDAQ_REALTIME_BRIDGE_INTERFACE_VERSION`
to 3.

The downside of this approach is that every app will have to call this
function irrespective of the transport. It is not ideal but considering
the alternatives, it is a good approach while we are still trying the
define the final API.

Here are the alternatives considered:

## Add a new set_function_table function to the bridge API (This PR) 

**Pros:**
- Very simple.

**Cons:**
- Requires all applications to call it irrespective of the bridge.
- Sequence of `cudaq_bridge_*` calls is loosely defined.

## Have the dispatcher wrap a bridge instance

**Pros:**
- Does not need to be called by applications
(`cudaq_dispatcher_set_function_table` can just call
`cudaq_bridge_set_function_table`).
- No need to worry about defining a call sequence.
- Call sequence could be moved in the dispatcher (the wiring can be
simplified for the app).

**Cons:**
- Adds much more coupling between dispatcher and bridge.
- Call sequence could be moved in the dispatcher (less flexibility in
the wiring).

## Returns a callback with cudaq_bridge_get_transport_context

Populates `cudaq_unified_dispatch_ctx_t` with an additional callback.

Can be passed through the dispatcher with
`cudaq_dispatcher_set_unified_launch`.

**Pros:**
- Follows along the idea of the `launch_fn` currently returned.

**Cons:**
- We are trying to deprecate the `launch_fn`.
- Significant API change and a precedent which can cause more API
changes in the future.
- Convoluted solution.

## Reuse the callback in cudaq_bridge_get_transport_context

Take advantage of the fact that `launch_fn` is not used in the CPU flow
and repurpose it to only pass the function table. (It already does; just
nullify the other arguments.)

**Pros:**
- Avoid API changes while we are still trying to determine the best
final API.

**Cons:**
- Hacky.

## Return the callback through the cudaq_cpu_dataplane_t

We are currently returning:

```c
cudaq_cpu_rx_poll_fn_t rx_poll;      ///< Non-blocking inbound poll; required.
cudaq_cpu_tx_publish_fn_t tx_publish; ///< Outbound publish; required.
```

**Pros:**
- Follows along the same callback mechanism.

**Cons:**
- Might come too late in the call sequence.

---------

Signed-off-by: Renaud Kauffmann <rkauffmann@nvidia.com>