[ENHANCEMENT] Use the custom Next.js deployment adaptors instead of open-runtimes

Deployment adapters on Next.js are now stable! This means that we don't have to stick to the limitations of sniffing out build outputs and manually moving or modifying stuff.

Here are a few examples of why build adapters should be used:

1. Native static asset fetching
   It's currently really hard to map out all the static routes and media just by looking at the build output. Instead, the adapter can return an array of all static assets available to be pushed to the CDN:

staticFiles: Array<AdapterOutput['STATIC_FILE']>

2. Automatic configuration changes
   As I had suggested before, using standalone outputs for builds resulted in a much faster and smaller output size as compared to the standard builds. However, not everyone has migrated to the standalone output builds aswell as some people with completely static sites are probably running without the static export either. Instead, we can force an output type using the adapter to ensure the optimal builds are produced:

export interface NextAdapter {
  modifyConfig?: (
    config: {output: string},
  )
}

3. Further enhancements (caching, edge runtimes, middleware optimizations)
   Appwrite doesn't have any of these at the moment. Adapters can return which function has to be ran on the origin and which ones can run on the edge in the CDN

Using adapters also means that we wouldn't have to worry about maintaining open-runtimes to support every new major Next.js version. If a native adapter is made once, it will be supported forever

Documentation: https://nextjs.org/docs/app/api-reference/config/next-config-js/adapterPath

p.s. the nextjs team will be releasing more information on adapters next week