There were a couple of small bugs in the current implementation:

1. We would pass non-boolean, non-integer values through to `predictions.create` when it was an object with an interval, resulting in the blocking mode being used accidentally.
2. We would pass the boolean/integer values through to `wait` which would create a runtime error when the `wait` function expects an object.
3. We continued to poll for the prediction despite the blocking response returning the output data.

This PR addresses these three issues by checking if the run should be blocking and passing the correct arguments in the correct places. We also assume that if the returned prediction is not in `starting` state then it is completed. This isn't ideal but works for the moment.

Lastly, in  the case where the blocking request times out the client will fall back to polling at the default interval.

* Enable FileObject and blocking mode by default

* 1.0.0-beta.1

A first draft of this interface used `block`, but we ended up going with `wait`
(as either a boolean or a number) for the predictions.createPrediction method.
This commit brings the two implementations inline, removing the undocumented
and unintended `block` parameter.

This commit takes a first pass at documenting the `FileOutput` and `wait` parameters introduced in 1.0.0 as well as calling out various potential gotchas with the API around URLs and data-uris based on feedback from the issues.

This change has now been reverted while we figure out how to provide a more consistent implementation.

The original code was intended to shim in support for the webcrypto
interface in Node 18, which was included indirectly as `webcrypto`
in the "node:crypto" module or globally via the
`--no-experimental-global-webcrypto` flag.

This change has caused many issues with bundlers and static analyzers
which do not like the obfuscated call to `require()`.

Node 18 will no longer receive security support as of 30 April 2025[1]
and as such it feels like we can now drop this workaround in favor of
documenting alternative approaches.

[1]: https://endoflife.date/nodejs

This PR adds support for passing `AbortSignal` to all API methods that
make HTTP requests, these are passed directly into the native `fetch()`
implementation, so it's up to the user to handle the `AbortError` raised,
if any.

```js
const controller = new AbortController();
try {
  const prediction = await replicate.predictions.create({
    version: 'xyz',
    ...,
    signal: controller.signal,
  });
} catch (err) {
  if (err instanceof DOMException && err.name === "AbortError") {
    ...
  }
}
```

The `paginate` function also checks to see whether the signal was
aborted before proceeding to the next iteration. If so it returns immediately
to avoid making a redundant fetch call.

This allows the client to take advantage of various frameworks that provide
an `AbortSignal` instance to tear down any in flight requests.

The endpoint returns a paginated list rather than an array