Context: #70 and #71

Even if moving toward a fetch-based design, this proposal does still not focus on supporting every type of requests as beacons.

For example, it's non-goal to support most of HTTP methods, i.e. being able to defer an OPTION or TRACE until page destroyed. It aldo does not make sense to allow setting keepalive: false for a deferred request.

We should look into fields of RequestInit and decide whether deferSend should throw errors on some of their values:

• keepalive: must be true. {deferSend: new DeferSend(), keepalive: false} conflicts with each other.
• url: supported.
• method: one of GET or POST.
• headers: supported.
• body: only supported for POST.
• signal: supported.
• credentials: enforcing same-origin to be consistent.
• cache: not supported?
• redirect: enforcing follow?
• referrer: enforcing same-origin URL?
• referrerPolicy: enforcing same-origin?
• integrity: not supported?
• priority: enforcing auto?

As shown above, at least keepalive: true and method need to be enforced.

If going with this route, can we also consider the PendingRequest API approach that proposes a subclass of Request to enforce the above?