Refactor access to repository storage and weights
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=358419)
</details>
<!--IssueSummary end-->
## Problem
Currently, in order to access information for [repository storage configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/c9127868555e6a2a7f5b6169c2a72e1a8fad8a9a/config/gitlab.yml.example#L1168) (like `name`, `path`, `gitaly_address`) we use the settings `Hash` directly: `Gitlab.config.repositories.storages` (or `Settings.repositories.storages`).
To load stored repository storage weight we then use the settings `Hash` and and lookup the stored weights `ApplicationSettings#repository_storages_weighted[<name>]` in `ApplicationsHelper#storage_weights`.
## Proposed Solution
Instead of using underlying implementation directly to lookup storage attributes and their weights we should it in a Object `Repositories::Storage` having methods like `#name`, `#path`, `#gitaly_address`, `#weight` etc. A collection of storages could be wrapped in `Repositories::Storages` instead.
## Why?
In this case, the use of primitive data types (see [PrimitveObsession](https://wiki.c2.com/?PrimitiveObsession)) is not very convenient and can be error-prone leading to subtle bugs. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75993#note_895124425
issue