[hw,entropy_src,dv] UVM TB forces signals/paths of prim_flop_2sync-internal signals

Nobody has claimed this yet.

### Description

The entropy_src UVM TB disables the CDC randomization of certain `prim_flop_2sync` instances. It does this by collecting a list of such instances in an array called `disabled_prim_cdc_rand_delays` that is in the `cip_base_test` used to force signals, which are internal to `prim_flop_2sync`

```systemverilog
virtual task run_phase(uvm_phase phase);
// Disable random delays in specific `prim_cdc_rand_delay`s even if CDC instrumentation is
// enabled. (See `cip_base_env_cfg` for details.)
foreach (cfg.disabled_prim_cdc_rand_delays[i]) begin
string path = {cfg.disabled_prim_cdc_rand_delays[i],
".gen_enable.cdc_instrumentation_enabled"};
`DV_CHECK(uvm_hdl_force(path, 1'b0));
end
super.run_phase(phase);
endtask
```

This creates assumptions of how the prim is built up internally, which cannot be made! It assumes a path `.gen_enable.cdc_instrumentation_enabled` existing inside of a prim.

This works for the generic prim implementation and also properly for the Nuvoton prims, as they are based on the same code. However, this does not work for a general prim and defeats the purpose of the prim library that abstracts the implementation away.

cc @andreaskurth, since you, I believe, implemented that in the first place.
cc @davidschrammel @rswarbrick @martin-velay

Start in cip_base_test and its run_phase, focusing on disabled_prim_cdc_rand_delays and the uvm_hdl_force path construction. Compare how the entropy_src UVM TB interacts with prim_flop_2sync and its generic and Nuvoton implementations. Done means CDC randomization can be disabled without assuming the prim's internal .gen_enable.cdc_instrumentation_enabled path.

Written by the indexing model from the issue text.