Content-Type, and potentially other headers, for the different types of feeds

[Svish]

Is your feature request related to a problem? Please describe.
Writing routes in Next.js which will return feeds generated by this library, but unsure
what headers to send with the response.

import { NextResponse } from 'next/server'
import { createFeed } from '@/feed'

export async function GET() {
  const feed = createFeed()

  return new NextResponse(feed.rss2(), {
    headers: {
      'content-type': 'text/xml; charset=utf-8', // Hopefully correct ... ?
    },
  })
}

Describe the solution you'd like
The current .rss2(), .atom1() and .json1() functions just return a string. Would be great if there were alternatives to those which simply returned standard Response objects with the rendered feed as the body and appropriate headers already setup.

import { createFeed } from '@/feed'

export async function GET() {
  return createFeed().toResponse('rss2')
}

Describe alternatives you've considered
Can of course just do it manually, like everyone else using this are probably doing, but I'm guessing that serving the rendered string from a server is probably one of the most common things to do with this library, so would be great if this could be handled right out of the box. 🧙‍♂️

[Svish]

Would also be cool if there was a cache header related to the ttl added on the feed, or something like that.

[webketje]

Proper type for RSS is application/rss+xml. IMO you bring up a valid concern: users are not sure which content type headers to match to different feed outputs, and most uses of this library will at some point involve serving its output, whether it be through a Node server or through Apache or Nginx as the output of a Node static site generator.

But I think the solution would simply be to add a Serving feeds section in the docs mentioning the matching content types OR to change the output of the feed methods to return an object with properties, eg const returnValue = new String('...'); returnValue.contentType = 'application/rss+xml' (using new String in example to avoid breaking change)

Cache headers IMO are out of scope for a data-format rendering library

[Svish]

@webketje That sounds good to me, would be very helpful, without changing the scope of the library.