Currently definePlugin and defineRule are doing double duty:

1. Providing type safety (standard defineConfig pattern).
2. Converting a plugin/rule to be ESLint compatible

Combining the two duties is probably confusing to users. Users are familiar with the defineConfig pattern and these functions generally don't do anything at runtime - just require a specific type as param and return the input untouched.

I think we should add a separate function eslintCompat which does the conversion to an ESLint-compatible plugin.

Related to #18610. eslintCompat would go in the @oxlint/plugin package along with definePlugin and defineRule.