Unify config to config/{domain/functionality}.yaml

[choinek]

@pkarw what do you think about implementing storage_strategy the same way I did with ocr_strategies, i.e., not as separate files, but as a single config?

This is a commonly accepted practice, for example, in Symfony projects where configurations are neatly aggregated in YAML files "per package."

Here, it could also be config/ocr_strategies.yaml and config/storage_strategies.yaml – with environment variable loading right away (currently, it's not universally implemented, but a universal class loading configuration would take care of it as part of this task )

EDIT: it's already done https://github.com/pilosus/piny

[choinek]

We could also remove this:

STORAGE_PROFILE_PATH=./storage_profiles

because the configuration will automatically be in config/* :)

And... if someone configures a storage profile, they can use it (by namespace) and even name it in their app as they want, allowing for multiple profiles.

s3_home
s3_work
s3_work_super_restricted
etc

Currently, we are restricted to a single config per library (they can't change it using the API).

So names won't be connected with type - type will be in class (like proposed for ocr_strategies).