Nextlove Edge Support MVP Steps

[seveibar]

In relation to: #82

The PR is too big and dangerous as is. This issue is to design an approach for getting edge-support merged

First let's get some opinions out of the way

• We will introduce withRouteSpecEdge to avoid a breaking change. This means it's an EDGE-COMPATIBLE withRouteSpec, it still shares the exact same API and types as withRouteSpec
• We will introduce an example app that uses edge e.g. example-edge-todo-app, this app also ideally deploys somewhere on cloudflare or vercel edge
• Introduce the edge term sparingly. Nextlove will work on both edge and lambda, so avoid any "edge-specific" terminology

If you disagree with the above, we can't move on to what's below

1. Propose changes to nextlove API e.g. the req.Response object that make nextlove compatible with edge. Do not introduce withRouteSpecEdge or any special edge handling
2. After the API changes are in, build withRouteSpecEdge (NOTE: withRouteSpecEdge is lambda and edge compatible)
3. Replace withRouteSpec with withRouteSpecEdge and deprecate withRouteSpecEdge

CC @itelo @codetheweb @razor-x

[itelo]

Edge runtime only supports web native API, so some things we do in the generated scripts are not allowed, and we should move them to a new package nextlove-generate, nextlove-generate maybe?

Replace withRouteSpec with withRouteSpecEdge and deprecate withRouteSpecEdge

Maybe we should make the createWithRouteSpec return an object with withRouteSpecEdge and withRouteSpec, this would make the types so much ease.

Another idea could be to put in the route_spec the runtime something like

const route_spec = {
  auth: "none",
  method: ["GET"],
  runtime: "edge" | "nodejs" // where default is nodejs
} as const