read_bigwig improvements

[casblaauw]

Description of feature

When reading in bigwigs, we should probably check whether chromosome names match between the bed file and the bigwig file. Currently, you get an unclear error after the processing started:

2025-04-30T21:16:20.356489+0200 WARNING Filtered 47226 consensus regions (not within chromosomes)
2025-04-30T21:16:21.438799+0200 INFO Extracting values from 37 bigWig files...
---------------------------------------------------------------------------
_RemoteTraceback                          Traceback (most recent call last)
_RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/lustre1/project/stg_00002/lcb/cblaauw/software/mambaforge/envs/crested_py311_tf216_v4/lib/python3.11/concurrent/futures/process.py", line 261, in _process_worker
    r = call_item.fn(*call_item.args, **call_item.kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/lustre1/project/stg_00002/lcb/cblaauw/python_modules/CREsted/src/crested/_io.py", line 96, in _extract_values_from_bigwig
    total_bed_entries = idx + 1
                        ^^^
UnboundLocalError: cannot access local variable 'idx' where it is not associated with a value
"""

The above exception was the direct cause of the following exception:
...

Also, as a more personal thing, I'd like to be able to provide a list/dictionary of bigwig paths to the function. Sometimes I want to use a subset of bigwigs in a directory, or bigwigs spread across multiple directories, and providing a list would be easier than making symlink dirs.

[casblaauw]

Okay, the error wasn't actually due to mismatched chromosomes between the bed and bigwigs, since if you have that, it actually silently works and reads in nans. This was due to the bedfile chroms not matching the genome chromosomes, resulting in all regions being filtered out. Both should be checked before.

[casblaauw]

Another improvement I should add whenever I get around to this issue: bigwigs can theoretically have negative values, even though they're usually not expected. We should probably raise a warning when this happens, since this can silently break a good amount of stuff (in my case, model weights immediately turned into nans since CosineMSELogLoss doesn't like negative values).