feat: typed API definition

[anuragkumar19]

🔗 Linked issue

#364

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This change will allow developers to define their api schema at one place and get type-safe fetch client.

Resolved #364

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[danielroe]

This looks really great, and thank you so much for your work on this.

I think it makes sense for these types to live in ofetch, and I think the schema makes sense:

[url: string]: {
    [key: 'default' | HTTPMethod]: {
      request: {
        body?: BodyType;
        query?: QueryType
      };
      response: ResponseType;
    };
  };

It might also allow us to do things like define error types in future.

My one note is that I think we should spend some additional time thinking about the params implementation as this will require runtime code changes as well as just types.

Finally, having said that, the tricky thing will be to properly handle type inference when (for example) hitting and endpoint that has multiple methods with multiple valid request types, each mapping to a method.

Writing those types will be complex.

For that reason, I would like to see some type tests bundled with this PR, for example similar to ones we have in Nitro, covering the way these types are used and ensuring we don't cause regressions.

[anuragkumar19]

I also thought that params can also be inferred from url.

This can be used to extract params from url.

For test I think I should first write test for types (will be another pr) of current version of ofetch, so then when new changes are merged it would be ensured that they are backward compatible. Additional tests will be written for new types.