feat: add signal to EIP1193RequestOptions

[deodad]

This PR address #1701. If the approach looks good I'll extrapolate to the rest of the actions where this makes sense.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 63a7eca

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[tmm]

Excited for this! Some random code style feedback.

[deodad]

Excited for this! Some random code style feedback.

thanks—applied

[jxom]

Happy to continue with the other Actions too.

[deodad]

I took an initial stab at it. It's ok but having done it this way it might more sense to figure out all the changes required for an action and then go through each one and apply all the changes:

1. accept requestOptions
2. make sure RequestErrorType is included in the error type
3. update the docs page to include requestOptions

a couple others that I'm not sure about but seemed useful:

1. add a test case to the actions tests for requestOptions. wasn't sure if adding to each action is worth it or too redudant
2. explicit handling of request errors in catches. for actions that have extra handling that wrap errors in a specific error type would it make sense to check for AbortError or generally for non-base errors and instead immediately rethrow unwrapped?