Initializes the Viv runtime for the host application at hand by registering
its content bundle and Viv adapter.
This function may be called more than once to re-initialize the runtime with a different content
bundle and/or adapter, with a caveat: re-initialization is only safe when the host application also
starts fresh, meaning the new adapter's HostApplicationAdapter.getVivInternalState returns
null and no simulation data from a prior initialization persists. If the content bundle changes
but old state persists (whether VivInternalState or the actual simulation data), the runtime
may become unstable, because components in the old state may reference action names, plan names,
or other definitions that do not exist in the new bundle. The actual supported use case for
re-initialization is a context like testing, where each initialization begins with a clean slate.
If the given content bundle and adapter do not pass validation. In cases of multiple
structural issues, only the first will be reported (to keep error messages manageable).
Initializes the Viv runtime for the host application at hand by registering its content bundle and Viv adapter.
This function may be called more than once to re-initialize the runtime with a different content bundle and/or adapter, with a caveat: re-initialization is only safe when the host application also starts fresh, meaning the new adapter's HostApplicationAdapter.getVivInternalState returns
nulland no simulation data from a prior initialization persists. If the content bundle changes but old state persists (whether VivInternalState or the actual simulation data), the runtime may become unstable, because components in the old state may reference action names, plan names, or other definitions that do not exist in the new bundle. The actual supported use case for re-initialization is a context like testing, where each initialization begins with a clean slate.