fix(server-renderer): respect compilerOptions during runtime template compilation

[skirtles-code]

Currently, only the deprecated form of isCustomElement is respected when performing runtime template compilation with SSR. All other compiler options are ignored. e.g.:

import { createApp } from "vue"
import { renderToString } from "@vue/server-renderer"

const app = createApp({
  template: `<mjml></mjml>`
})

// This works, but it is deprecated and no other compilerOptions are respected
app.config.isCustomElement = tag => tag.startsWith('mj')

;(async () => {
  const markup = await renderToString(app, {})
  console.log(markup)
})()

This PR attempts to use compilerOptions consistently with other forms of template compilation.

Unresolved problems:

• The cache does not take the options into consideration. It was already ignoring isCustomElement and I didn't want to expand the scope of this PR. Now fixed.
• The logic to resolve the options is duplicated with runtime-core/src/component.ts. Extracting the logic to a shared function should be a fairly painless refactor.
• The deprecated forms of isCustomElement and delimiters do not show warnings during SSR.

[yyx990803]

The runtime compiler options are limited and largely serializable. We can call fn.toString() if isCustomElement is present, and isNativeTag is in fact constant since server-renderer implies runtime-dom.

So we can resolve the options first, serialize it to get a cache key that takes options into account.

[skirtles-code]

OK, I think that should be working now.

There are some potential edge cases around using fn.toString(), e.g. if someone uses a utility function to create isCustomElement functions they will likely have the same toString but different values caught in their closures. This probably isn't worth worrying about given the templates also have to be a perfect match. If someone did encounter that extreme edge case, it should be possible for them to work around it by passing a cache-buster in the compilerOptions.