feat: align plugin api with Extension

[eliassjogreen]

Continuation on #9850. This pr aligns the plugin api with the new runtime extensions introduced in #9800. I have not yet limited any of the access to the Extension struct so currently they are the exact same (Except js, and middleware support which probably would not be needed nor used. Reason for not implementing them is that they need access to the JsRuntime which op_open_plugin does not have). The Extension struct should probably be split into a few traits (JsExtension and MiddlewareExtension) or a new DynamicExtension struct could be introduced.

cc @crowlKats @AaronO

[lucacasonato]

@eliassjogreen Could you merge with master?

[eliassjogreen]

Deno.core.opSync and Deno.core.opAsync should probably be exposed outside of core in the normal Deno namespace, right?

[ry]

Deno.core.opSync and Deno.core.opAsync should probably be exposed outside of core in the normal Deno namespace, right?

Why's that? These are not methods we generally want user code to call. I suppose the distinction is blurred in the case of plugins.

[ry]

LGTM - thanks @eliassjogreen for giving the plugin API some love.

[AaronO]

Deno.core.opSync and Deno.core.opAsync should probably be exposed outside of core in the normal Deno namespace, right?

Why's that? These are not methods we generally want user code to call. I suppose the distinction is blurred in the case of plugins.

One possible workaround would be to have openPlugin return { opSync, opAsync, ... } to limit exposure