docs: Unify capabilities list for kv services

[lqhuang]

In the very first, I want to migrate sled/rocksdb services to typed_kv. But I found typed_kv has its own data schema (metadata + value), it seems would break loading and writing of existed data? Discussion is required here.

Then I found the type crate::Capability doesn't have scan flag, is this intentional result or deliberate design?

Then for this PR,

1. Add a scan flag to general Capability
2. Simply reformat capabilities docs of all KV services to the same.

Notes:

1. cargo test passed locally.
2. scan flag for those services capable with scan haven't set to true yet.

Further discussions:

1. Should we have similar typed_kv migration for sled/rocksdb/memorycache/redis
2. Should we split services into different categories (and project layout): 1. Block Storage 2. Object Storage 3. KV Storage, more over also have different capabilities: 1. BlockCapability; 2. ObjectCapability, 3. KvCapability

This's my first PR for OpenDAL 😀 Please check more in details.

Thanks for your efforts!

Sincerely,
Lanqing

[Xuanwo]

Then I found the type crate::Capability doesn't have scan flag, is this intentional result or deliberate design?

Yes, they are by design. We removed scan in previous refactor.

Should we have similar typed_kv migration for sled/rocksdb/memorycache/redis

Not. They can't be migrated to typed_kv since they can't store a typed_kv::Value with zero cost.

Should we split services into different categories (and project layout)

No, we don't do refactor like this kind. Current code structure is clean and easy to understand.

[lqhuang]

@Xuanwo Thanks for reply!

I reverted change of scan flag. Now it's just a docs improvement change.

Yes, they are by design. We removed scan in previous refactor.

Any material or discussion about the design?

[suyanhanx]

Thank you for fixing this!
Here are some informations about the relation between scan and list.

#2072

Wish it is help to you.

[Xuanwo]

Thanks!