enhancement: trx-control client built into trxd to implement/bridge extensions automatically

[gx1400]

@mbalmer and I have spoken on the Matrix/Element that a feature enhancement for trx-control should include the ability for extension functions to be executed automatically by trxd without a separate trx client running

An example of this is for the proposed cloudlog extension:

1. A built-in 'reflector'/'bridge client'/'extension client' could connect to trxd
2. the built-in client would be configured to start-status-updates for a specific transceiver
3. the client would consume status-update messages, parse them, and execute a pre-defined function in an extension (for example cloudlog.lua radio api function (for sending radio tuning states to the cloudlog api)

[gx1400]

Proposed implementation idea in /etc/trx.yaml

Existing configuration:

trx:
  ft817:
    device: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_FTT7H3KH-if00-port0
    speed: 38400
    driver: yaesu-ft-817

  ic7300:
    device: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_IC-7300_02050237-if00-port0
    speed: 115200
    driver: icom-ic-7300
    configuration:
      controllerAddress: 0xe0
      transceiverAddress: 0x94

extensions:
  cloudlog:
    script: cloudlog
    configuration:
      url: "https://cloudlog.domain.tld/index.php/api"
      apiKey: "xxxxx"

Proposal (for discussion)

extension-bridge:
  cloudlog-ic7300:
    extension: cloudlog
    configuration:
      function: radio
      trx: ic7300

  cloudlog-ft817:
    extension: cloudlog
    configuration:
      function: radio
      trx: ft817

[mbalmer]

In more generic terms, a mechanism for the different threads and Lua states to communicate with each other is needed.