feat: add Go support

[Meza (meza)]

Adds Go bindings for terminal automation using the same in-process Rust engine as the JavaScript and Python bindings.

This PR contains the public Go API, its purego runtime bridge, and the private Rust native adapter. Source checkouts build the adapter from the same revision and select it explicitly with TUI_TEST_GO_NATIVE_LIBRARY.

• Provides typed clients, input controls, inspection, composable text/style/link locators, waits, assertions, screenshots, recording, restart, and failure-aware cleanup.
• Exposes terminal modes, colors, cursor state, hyperlinks, exit signals, structured diagnostics, traces, and engine-owned failure artifacts.
• Keeps runtime calls, ABI conversion, and memory ownership behind internal/native; session, diagnostic, trace, artifact, and recording policy remain in the shared Rust engine.
• Covers timeout inheritance, explicit zero overrides, shared-session preservation, retry cleanup, public operation names, recording defaults, and ABI v3 behavior.
• Documents and tests the source-build path without adding CI or packaged native libraries.

The go-binding-automation follow-up contains the delivery layer: embedded native libraries, content-addressed extraction/cache handling, generated C header and compiler-backed ABI layout verification, cbindgen, CI checks, seven-target release assembly, and published nested-module packaging. GitHub does not support first-class stacked PRs across forks, so that follow-up PR will be opened after this PR merges.

[Meza (meza)]

@microsoft-github-policy-service agree

[cpendery (cpendery)]

Appreciate the work to add go support to tui-test, a few small notes

1. I'd like to hold off on adding go support until we get the 0.1.0 release / features complete
2. Once we are ready to start adding go support, let's split the pr because 7k lines is just too big. In PR 1, let's add the support without any CI / packaging changes, and those can get added in a follow up
3. I think purego is an okay option, but maintaining the abi might be some extra effort. Why'd you decide on it vs. using a different library that requires cgo

[Meza (meza)]

Hey, sounds good! I'll strip out just the go changes and put the ci/packaging in a stacked one for later.

As for purego:

I originally used cgo and the first implementation worked, but it made the binding difficult to install and use.

Users needed cgo enabled, a C compiler, the correct Rust library, build flags and runtime library settings. This meant that go get was not enough. It also made cross-compilation and deployment more complicated.

I changed the binding to use purego so users only need to run:

go get github.com/microsoft/tui-test/bindings/go

The Go module now includes the compiled Rust libraries. At runtime, the binding selects the correct library, extracts it to the user’s cache, checks its contents and loads it automatically.

[Meza (meza)]

cpendery (@cpendery) I've stripped it back, go the packaging/ci ready on another branch but I can't do stacked prs from forks, so that will have to happen if this gets in at one point. No rush, I can still use this locally for my own project in the meantime

[cpendery (cpendery)]

Meza (@meza), we should be ready to update this pr to work with the new api for 0.1.0

[Meza (meza)]

Oh cool, let me see what needs to be done! Shall I target a specific branch?

[Meza (meza)]

cpendery (@cpendery) updated!

[cpendery (cpendery)]

Meza (@meza) can you remove this as this issue is fixed and should be working now? please do it in the testing follow up pr

[Meza (meza)]

oh yes, one sec!