Disable Emulating WinterCG by default, however ask to enable it interactively in `edgespec init`

[seveibar]

Emulating WinterCG is a way forcing endpoints to be maximally compliant with the standard, but just like with databases, people rarely build for multiple targets. We will suffer from the Lowest Common Denominator problem because every environment has additional features that users will want to access.

We should be the best standard for building APIs, and allow users to build for multiple targets and make usability a higher priority than compliance to maximize adoption and reduce initial onboarding struggles.

However, in edgespec init we should allow users to select this constraint.

As an anecdote, wintercg-minimal failed to build one of my projects, the build error was difficult to parse #35 so I gave up using edgespec. When I woke up this morning I felt a bit more confidence so I dug in and figured out it was the wintercg emulator and figured out it could be disabled, but our users won't have this same determination- this is mostly unrelated to the issue above since the emulator will eventually stabilize, but there is something to be said about being generous with emulation by default (lifting environments to the WinterCG standard without constraining them)

[codetheweb]

I disagree, one of edgespec's main selling points is that it can be run on the "edge". #35 is an unrelated error and we can definitely work to make error messages more friendly if you attempt to import node:*.

[codetheweb]

people rarely build for multiple targets

This isn't the case when building a module service, which should be maximally compatible by default.

[codetheweb]

this catches issues that you wouldn't think of at first, e.x. attempting to move fake-2n to edgespec and it uses jsonwebtoken which is not wintercg compatible:

[seveibar]

I think your use case around 2n is compelling, we could make edgespec dev prompt on first run when creating the config