Allow pre-parsed config objects to custom types

[WebReflection]

While there's more happening in this MR pyscript/pyscript#1698 that's not worth explaining in here, it became evident custom types might pass a config reference that is already an object literal, not a string.

Currently, the config is also used to define the unique identity of any interpreter bootstrap, but this assumption fails short with custom types, because these are all based on the initial config that's passed along, at least on the main thread (workers can have random configs without issues because workers are all unique by design/default).

My concern is that it shouldn't be needed to re-parse a config when such config has already been parsed or sent as object literal to define the custom type, but current logic makes that assumption and, in the worst case scenario, we JSON.parse(config) twice which is definitively not a real bottleneck, but it feels unnecessary, hence there's room for improvements.

Note keep in mind the config is needed to also resolve the URL of the running code and provide safe defaults to the rest of the logic so this is effectively a low priority but definitively a nice to have improvement around polyscript custom-types logic.

[WebReflection]

This issue keeps coming up and there are more findings:

• if a config is passed as object, it's not clear from where the files should be resolved, if not automatically from the current location path. This must be working as intended for both main and worker
• custom types should really accept an object without further parsing because in PyScript, as example, we already do a way stronger validation of the config with better errors too and a better TOML parser and it makes literally no sense to accept a config as string there

[WebReflection]

The latest polyscript probably fixed this too but I need to test in PyScript ... will close this as done if that's the case.