`@script()` with no explicit opset silently exports functions under a placeholder domain (`this`)

[andife]

script()'s default when no opset is passed
(onnxscript/_internal/main.py):

opset = opset or values.Opset("this", 1)

This is also the exact form shown in script()'s own docstring example:

@script()
def log2(x):
    ...

So the documented, simplest way to use the decorator produces a function
whose ONNX domain is the literal string "this" — which reads like it
could be a real (if terse) namespace rather than an internal placeholder,
and nothing warns or errors when a function still carrying it gets
exported into a .onnx file.

Ran into this concretely while running a corpus-wide census of ONNX
models on the Hugging Face Hub: found real, independently-uploaded models
(e.g. Discourse/parakeet-tdt-0.6b-v3-onnx)
shipping a bundled preprocessor subgraph
(istupakov/onnx-asr's
preprocessors/nemo.py) with a node/local-Function in domain this,
traced back to exactly this default. Filing a companion issue there too,
but the shared default here means any other @script() user who omits
opset= is a candidate for the same collision-prone domain.

Two independent onnxscript-authored models both leaving their local
Functions under domain this would collide if ever composed/merged into
one graph (e.g. via onnx.compose), since nothing distinguishes one
tool's placeholder from another's.

Two possible directions, either would help:

1. Warn (or error) at export time if a function is still carrying the
   placeholder Opset("this", 1), prompting the author to set a real one.
2. Pick a sentinel that can't be mistaken for a real domain (e.g. an
   empty string, or something clearly internal like
   "onnxscript.unset"), so it's obviously wrong if it leaks through
   rather than looking like a plausible vendor namespace.

Happy to elaborate or send a PR if there's an appetite for either
direction.