[chip-test] Improve chip_csr_mem_rw_with_rand_reset test

Nobody has claimed this yet.

### Description

PR #24020 fixed the `chip_csr_mem_rw_with_rand_reset` by increasing the default wait timeout for chip-level sequences to have sufficient time to write-read check all 2612 CSRs in Earlgrey before injecting a reset. This works but there would be smarter ways to handle this. For example:

1. Beginning of 2024, we've added a `stop_transaction_generators()` function to the `dv_base_env_cfg` class. This function allows checking if someone wants to do a reset and can be used to abort loops doing checks. The challenge with this approach is that the sequence doing the write-read check lives in `csr_seq_lib.sv` which does not know this configuration class. When doing this, we would need to be careful to not break block-level DV sequences as this is shared DV code.

2. As outlined [here](https://github.com/lowRISC/opentitan/blob/663be282861048ec1d4eb31abbe8e70d06543220/hw/dv/sv/csr_utils/csr_seq_lib.sv#L15_L19), we could use the `num_test_csrs` parameter or the `num_csr_chunks` plusarg to reduce the number of CSRs (per chunk). This may have an impact on the chip-level coverage. We should tune the number of tests and number of chunks accordingly.

Start with hw/dv/sv/csr_utils/csr_seq_lib.sv and the dv_base_env_cfg stop_transaction_generators() entry point, then inspect chip_csr_mem_rw_with_rand_reset and the existing timeout change in PR #24020. Compare aborting the CSR loop with tuning num_test_csrs or num_csr_chunks, while checking that block-level sequences remain unaffected. Done means the chip test completes reliably with reset and its coverage remains appropriately tuned.

Written by the indexing model from the issue text.