Added a prefix config setting to the previewHandler to add a prefix to the redirect response

[cloetensbrecht]

By adding a prefix setting to the previewHandler, it will be possible to allow a prefix to the redirect uri.
This will solve the issue where a same url is used in different roots.

An example of the configuration:

In your workspace, add a preview property to each root where you want to add a preview path to.
If you do not want to add a preview to a root, you can simply omit the preview property.

const location =
	process.env.NODE_ENV === 'development'
		? `${process.env.NEXT_PUBLIC_APP_PROTOCOL}://${process.env.NEXT_PUBLIC_APP_HOST}`
		: ''

Config.workspace('My-workspace', {
	roots: {
		myfirstroot: Config.root('My First Root', {
			contains: ['TypeA'],
			preview: `${location}/api/preview/myfirstroot`
		}),
		mysecondroot: Config.root('My Second Root', {
			contains: ['TypeA'],
			preview: `${location}/api/preview/mysecondroot`
		}),
		myrootwithoutpreview: Config.root('My Root Without Preview', {
			contains: ['TypeB']
		})
	}
})

Because our preview routes are separate for every root, we can simply create a single /api/preview/[root]/route.ts file to catch all our preview routes. With the extra prefix config setting of the previewHandler, we can now pass the desired prefix for each root.

import { cms } from '@/cms'

export const GET = (request: Request, {params}: {params: {root: string}}) => {
	return cms.previewHandler(request, {prefix: params.root})
}

This will redirect our preview routes as follows:

/api/preview/myfirstroot?token=123456		>	/myfristroot/path-of-my-entry
/api/preview/mysecondroot?token=123456		> 	/mysecondroot/path-of-my-entry

We can accommodate each root separately within our app folder, even though both slugs for the different roots are the same (path-of-my-entry).

/app/myfristroot/[...slug]/page.tsx
/app/mysecondroot/[...slug]/page.tsx

Without the extra prefix config setting both preview urls would be redirected to /path-of-my-entry. This will make it impossible to know in which root they are. This pull request solves this issue.