new feature: irys.xyz service

### Feature Description

An irys.xyz storage service for opendal.

### Problem and Solution

I understand opendal is a path based storage interface. The functions `read(path)` and `write(path, content)` have to be implemented.

After some research, it seems this is possible by doing 2 things:

1. Building a locally running irys TS SDK wrapper that exposes all necessary functions (upload, download, etc.) via an API
2. Writing the opendal irys service that utilizes this API to interact with Irys

#### Requirements check
- Irys offers the ability to set tags on an uploaded chunk: https://docs.irys.xyz/build/d/sdk/upload/uploadFile
- As all data on irys is public, one can use the graphQL interface to query chunks by the path tag: https://docs.irys.xyz/build/d/graphql#query-arguments
- Deletion does not exist on irys. So the `delete(path)` operation does not carry out any action. Instead, data just expires after the intended lifetime of the data is reached. Note - currently, the irys sdk only offers permanent / perpetual (forever) storage. So deletion is indeed not possible.

#### Path mapping in Irys
As briefly mentioned before, paths can be stored alongside chunks by setting them as tags.
So, how does one deal with updates to file paths? That would mean multiple chunks would exist with the same path tag.

It seems, that each upload on irys has a timestamp associated with it, by which the results could be sorted: https://docs.irys.xyz/build/d/graphql#results-fields

I am willing to implement this entirely on my own to not burden the opendal team and giving this feature request a fighting chance.

### 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 with the proposed local TypeScript SDK wrapper and its upload/download API, then map OpenDAL's read(path) and write(path, content) operations to Irys tags and GraphQL path queries. Define how timestamps resolve duplicate paths and document the no-op delete and expiration behavior; done means the service design and required operations are implemented and verified.

Written by the indexing model from the issue text.