feat: CAS backend normalization

[migmartri]

Currently, setting up an OCI registry is required to use Chainloop because it's used to store artifacts during the attestation process.

This OCI registry acts as a storage backend for the CAS

The issue is that OCI is currently the only type of backend that the system support, we want to make sure that the CAS and controlplane can be extended to use other storage backends, i.e S3, GCS, Artifactory, ...

This task has the following goals

• Decouple the concept of OCI repository from the CAS backend and make it just one kind of backend
• Replace the oci_repository concept and signup flow from the controlplane and make it generic so it can hold other backends in the future.
• Make storage backend optional as explained here Inline CAS backend #201

In other words, this task is about setting the foundations of allowing the setup of different storage buckets.

### Tasks
- [x] Make data model changes to migrate from oci_repositories to cas_backends. This should not be a breaking change and already registered OCI registries should still work. https://github.com/chainloop-dev/chainloop/pull/236
- [x] Keep cas secret/provider reference in the workflowrun so it does not get lost when changed https://github.com/chainloop-dev/chainloop/pull/237
- [x] List cas backends https://github.com/chainloop-dev/chainloop/pull/238
- [x] add cas backend https://github.com/chainloop-dev/chainloop/pull/239
- [x] Inline backend support https://github.com/chainloop-dev/chainloop/pull/247/files
- [x] Rotate credentials and soft-delete
- [x] Add inline backend as default
- [x] Update documentation  https://github.com/chainloop-dev/docs/pull/140
- [ ] Map digest -> cas backends
- [ ] Prepare CAS to support multiple-providers and on the fly selection

[migmartri]

Some of the changes that will come as part of the effort.

• An organization will be able to register multiple CAS backends, eventually from different types (OCI, inline, S3, ...)
• The operator will be able to choose which one of those is the default one
• The default one will be validated as part of the middleware (as of today) and used during the attestation process.
• There will be a new set of commands to operate on those backends
  • chainloop cas-backend set-default --id ....
  • chainloop cas-backend delete --id soft-delete the entry in the DB, does not delete credentials since they might be used in previous attestations.
  • chainloop cas-backend add oci ... basically the same command we have today in config set-oci-registry
  • chainloop cas-backend rotate oci --id ... ... creds. This will validate and rotate the credentials for a given backend. The reason this is a separate command is because it only operates on the credentials side of things.

WDYT?