new feature: suggestions for `Lister`

### Feature Description

Thought of a few `Lister` and `Entry` enhancements for your consideration.
(Affects public API)

### Problem and Solution

- `stat` returns `Metadata` which is okay, and `Lister` returns an `Entry` which is path +`Metadata`. But since `Lister` [doesn't guarantee metadata retrieval due to performance implications](https://github.com/apache/opendal/pull/6232#discussion_r2126959344), and Entry should be path +`Option` instead.
- Some user might still be ready for those performance cost, and for this `ListOptions` should have a key `with_metadata: bool` which ensures the metadata retrieval. This way the user decides performance vs results.
(they can still do this with an external `stat` call but user side code simplifies with this simple new option).
- Additionally, `stat` already has some options which might be useful in `Lister` as well (can be pushed down, if backend services support it),
- if_match
- if_none_match
- if_modified_since
- if_unmodified_since
- Suggestions for better naming,
- `deleted` -> `with_deleted`
- `versions` -> `with_versions`

what do you think?

### Additional Context

_No response_

### Are you willing to contribute to the development of this feature?

- [x] Yes, I am willing to contribute to the development of this feature.

Start by reviewing the public Lister, Entry, ListOptions, and stat APIs, including the linked discussion about metadata retrieval. Clarify the compatibility and backend-support implications before implementation; done would require an agreed scope for metadata, conditional options, and the proposed naming changes.

Written by the indexing model from the issue text.