Add to model ability to point to config file(s) which resulted in that record

thinking about bids-validator config file which could change level of a specific type of a result. While reporting to the user it might be useful to instruct why any given record got to be like it is

in dandi-cli we associate each result with a singular

```python
class ValidationOrigin:
name: str
version: str
bids_version: str | None = None
```

(I recall us working on refactoring to have `standard` and `standard_version`). So likely we would like to either add some explicit `List[ConfigurationOrigin]` construct depicting origin of the configuration (file, env var, ...) and then tools being able to annotating results with information about specific configuration file which effected that result. Thinking of the case where e.g. for openneuro there could be validator config provided by the dataset and then the one with overloads from openneuro.

User of the website then ATM just provided with a list of errors or warnings but there would be no specific description that e.g. error of having no subjects is specific to openneuro (its configuration for bids-validator, ref: https://github.com/OpenNeuroOrg/openneuro/pull/3184), and not of dataset itself or the original standard.

ref:
- https://github.com/bids-standard/bids-validator/issues/279