Refactor the registry to hold index instances

[mgax]

This patch simplifies the index registry: instead of storing index classes, and creating instances on the fly, it stores index instances that are ready to use. A different approach to addressing https://github.com/wagtail/wagtail-vector-index/issues/18 (though it's orthogonal to https://github.com/wagtail/wagtail-vector-index/pull/51; we could merge both).

The main case for storing index classes seems to be the ability to use multiple indexes for a given model, e.g. for a different embedding or chat backend.

• A different embedding backend means different embeddings are generated, so running ./manage.py update_vector_indexes should rebuild each set of embeddings. Therefore, it makes sense to register multiple indexes for the same model. With this patch, the model's get_vector_index() method would return the "default" index, and the user would call registry.register_index() with additional indexes.
• A different chat backend is ephemeral. Perhaps this should not be a parameter of the index itself. From reading the code, I can't figure out why this is even a concern of the vector index class.

[tomusher]

Thanks, this looks like a good implementation of this change.

I'm still in two minds about this one however;

• You are right that it doesn't make sense to specify an embedding backend (or a vector backend) as an instance attribute - this should probably be moved to a class attribute too.
• Yeah, chat_backend might be better off as an argument to query.
• That would leave us with no reason right now to store classes in the registry, but I am concerned about the loss of flexibility. If we make a decision to store instances now, and then decide there is more instance-level state that we need (or a developer wants to implement any on their own index), we have to reconsider this.
• The main use of the registry right now is for discovery of indexes when they are updated using the update_vector_indexes command. If we are proposing that for a developer to support different behaviours within the same index, they'd need to register multiple instances, would that cause duplication when rebuilding?

[mgax]

• If we are proposing that for a developer to support different behaviours within the same index, they'd need to register multiple instances, would that cause duplication when rebuilding?

Not sure about this one. I'm thinking of a use case where you store embeddings in both pgvector and something else (qdrant, weaviate?). Or generate embeddings using both OpenAI and GPT4All and store them separately to compare performance. But honestly, I don't have a good handle on all the reasons why people would want to parametrise indexes.

[tomusher]

The changes in #65 include changing the registry to hold index instances based on this PR. Thanks for this @mgax !