Remove hardcoded registry file

[lfoppiano]

This pull request refactors how the resource registry is handled across the sequence labeling models in the delft package. The main change is to allow the registry path to be set via an environment variable and to enable passing a custom registry to model constructors, improving flexibility and configurability. All model classes and the model factory function (get_model) are updated to support this new approach.

Resource registry handling improvements:

• Added a get_registry_path function to delft/__init__.py to allow the registry path to be configured via the DELFT_REGISTRY_PATH environment variable, falling back to the default location if not set.
• Updated the BaseModel constructor in delft/sequenceLabelling/models.py to accept a registry parameter and load the registry using the new logic if none is provided.

Model instantiation changes:

• Modified the get_model function and all model class constructors in delft/sequenceLabelling/models.py to accept and propagate the registry parameter, ensuring consistent use of the registry throughout the codebase.

[lfoppiano]

Here one example of use, I created a new registry with a new db path:

(delft) (base) ➜  delft git:(bugfix/fix-hardcoded-resource-file) ✗ export DELFT_REGISTRY_PATH=resources-registry2.json 
(delft) (base) ➜  delft git:(bugfix/fix-hardcoded-resource-file) ✗ .venv/bin/python -m delft.applications.grobidTagger date train --architecture BidLSTM_CRF
Loading data...
Using latest training file: data/sequenceLabelling/grobid/date/date-220311.train
637 total sequences
573 train sequences
64 validation sequences

max train sequence length: 12
max validation sequence length: 10

Compiling embeddings... (this is done only one time per embeddings at first usage)
error: embedding path for glove-840B is not valid /media/lopez/T5/embeddings/glove.840B.300d.txt
Downloading resource file for glove-840B ...
downloading https://huggingface.co/stanfordnlp/glove/resolve/main/glove.840B.300d.zip
data/download/glove.840B.300d.zip:   1%|▍                                                                       | 12.5M/2.03G [00:10<37:40, 957kiB/s]
[...]

[de-code]

Looking good.

Didn't quite expect the extend of necessary changes when I raised the issue.