Feature: include JS Hooks SDK @ quickjs engine

[WietseWind]

The QuickJS CLI (qjs.c) lib has the -I option which allows for 'injecting' (preloading) JS that will be available in the runtime.

Under the hood it does this:
https:/bellard/quickjs/blob/master/qjs.c#L502

Goal:

Limit the size of JS Hooks using a simple Hook SDK

Proposal:

Inject a "JS Hook SDK" @ the engine, so many helper fns I'm currently writing don't have to be part of every compiled Hook, as they are globally defined.

Implementation:

Proposed:

1. The HookSDK JS becomes part of the xahaud package, so new versions are part of the release & if they refer to native HookJS API's, they will always be available because they are part of the same xahaud release. Obviously the .bc version (compiled HookJS) should be included (?)

2. For development purposes: if config stanza is present to refer to an external .bc-like compiled JS Hook SDK, this one will be used instead of the embedded one, so we can locally add and test things by changing the JS Hook SDK, TS to JS, JS to BC, and then refer the local config to that .BC so we can immediately test the new SDK fns.

[tequdev]

In order to make the same Hook code available to multiple Hooks Enabled networks, it is desirable to be able to access TransactionType, sf fields, etc. by field name rather than by number.

like

`ttURITokenMint` in jshook code -> (xahaud package) -> `ttURITokenMint` -> 45
`ttURITokenMint` in jshook code -> (rippled package) -> `ttURITokenMint` -> another code

to avoid the following

`ttURITokenMint` -> 45 in jshook code -> (xahaud package) -> 45 -> `ttURITokenMInt`
`ttURITokenMint` -> 45 in jshook code -> (rippled package) -> 45 -> `ttXCHAIN_ADD_CLAIM_ATTESTATION`

[WietseWind]

Definitely true @tequdev - all to be added to the core lib :)