fix(useFetch): Add option to use stock FetchAPI error-like status codes behavior (non-breaking alternative)

[josh-hemphill]

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

⚠️ Slowing down new functions

Warning: Slowing down new functions

As the VueUse audience continues to grow, we have been inundated with an overwhelming number of feature requests and pull requests. As a result, maintaining the project has become increasingly challenging and has stretched our capacity to its limits. As such, in the near future, we may need to slow down our acceptance of new features and prioritize the stability and quality of existing functions. Please note that new features for VueUse may not be accepted at this time. If you have any new ideas, we suggest that you first incorporate them into your own codebase, iterate on them to suit your needs, and assess their generalizability. If you strongly believe that your ideas are beneficial to the community, you may submit a pull request along with your use cases, and we would be happy to review and discuss them. Thank you for your understanding.

---

Description

Solves same problem as #3092 , but provides a non-breaking solution, since users do expect the non-standard behavior, as it's more intuitive. But there are cases, especially when integrating with APIs, where stock FetchAPI behavior is necessary.

This adds an option throwOnErrCodes that is true by default, but can be disabled; in which case, http error codes will be accepted as successful responses, and populate the data field instead of the error field.

This also has the benefit of allowing someone to disable throwOnErrCodes and implement their own custom error detection in afterFetch hooks, since throwing inside one results in falling back to the useFetch error being populated.

Additional context

solves #2452
solves #526
solves #553
supersedes #572
related #2711

---

🤖 Generated by Copilot at 2ae0871

This pull request enhances the useFetch function with a new option throwOnErrCodes that allows users to opt out of throwing errors on non-200 status codes. It also adds tests and documentation for this new feature.

🤖 Generated by Copilot at 2ae0871

• Add throwOnErrCodes option to useFetch to disable error throwing for non-200 status codes (link, link, link, link)
• Update useFetch documentation to explain how to use the new option and handle error codes like the native FetchAPI (packages/core/useFetch/index.md, link)
• Add test cases to verify the behavior of useFetch with and without the new option, and with a custom error thrown in the afterFetch hook (packages/core/useFetch/index.test.ts, link, link)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.