Clearer names for dense storage implementations

[agourlay]

This PR is a bunch of mechanical renaming for dense storage related types and files.

The motivation is that we want to add soon new types of storages for multi-vector points, so it is better to makes things explicit.

[timvisee]

Just quickly skimmed it: are we sure this doesn't break compatibility, in terms of loading existing storage from disk?

[agourlay]

Just quickly skimmed it: are we sure this doesn't break compatibility, in terms of loading existing storage from disk?

This part is tested by our storage compatibility tests.
Only types are changed, no field names, I do not foresee any compatibility issues.

Do you maybe a specific scenario in mind?

[timvisee]

This part is tested by our storage compatibility tests. Only types are changes, no field names, I do not foresee any compatibility issues.

You're right. Brilliant! Thanks for confirming.

Do you maybe a specific scenario in mind?

Nope! Not anything other than what you've already covered.

[agourlay]

I just double checked, it seems the compatibility tests are not covering the memap & appendable memap configurations.
Will check how to add it quickly.

[generall]

I think it is safe to merge, cause those structs do not implement Deserialize anyway

[agourlay]

@generall excellent observation 👍

Then feel free to approve, I will work on improving the compat. tests independently from this PR.