* init modifications to fork

* adjust meta and fix readme

* Update fetch.bs

Co-authored-by: Andreu Botella <[email protected]>

* Update fetch.bs

* Delete review-drafts directory

Co-authored-by: Andreu Botella <[email protected]>

This introduction includes a list of changes with respect to the
WHATWG spec, to be updated as they're introduced, as well as a list of
planned features.

Fixes #16.

WHATWG specs, including the Fetch spec, use a stylesheet different
from the W3C default which WinterCG uses. This WHATWG stylesheet
supports various types of notes and boxes with specific classes that
are not supported in the W3C default stylesheet.

This change adds styling for these classes, giving them a style
consistent with that of various types of notes in the W3C stylesheet.

* Relax forbidden header restrictions for non-browser runtimes

Web browsers treat certain request and response headers as forbidden
–forbidden request headers are impossible to set in requests, and
forbidden response headers are always filtered off of even basic
filtered response (i.e. responses for same-origin fetches).

While some of these forbidden request headers make sense generally
(for example, `Date`, `Host`, `Transfer-Encoding`), others don't make
sense for implementers that don't support CORS or cookies. And the
only forbidden response headers (`Set-Cookie` and `Set-Cookie2`) only
make sense for implementers that support cookies.

To allow different kinds of implementers with different requirements,
this change adds a "conformance classes" section defining support for
CORS and cookies. It then changes the definitions of forbidden request
and response headers to depend on the user agent's conformance
classes.

* Update fetch.bs

Co-authored-by: Ethan Arrowood <[email protected]>

* Update fetch.bs

Co-authored-by: Ethan Arrowood <[email protected]>

---------

Co-authored-by: Ethan Arrowood <[email protected]>

Our CI deploy action currently asks a server at api.csswg.org to build
the spec, and then uses the response to that request as the build
output. However, it does not check that the response's HTTP status
code is successful, which can result in Internal Server Errors in that
server being "propagated" to this spec, rather than resulting in a
failed build. Similarly, fatal errors in building the spec (for
invalid Bikeshed syntax, for example) would result in the list of
errors being deployed.

This PR fixes that by allowing `curl` to fail for non-successful HTTP
status codes.