feat: begin lua-side stdlib, implement combinators & validators. also, beginning of docs, and add build, test, and rustfmt to CI

[klardotsh]

Holy guacamole, this came out to many more lines of code than I expected...

Included here are:

• the beginnings of seatrial's extremely light "standard library", or perhaps more accurately, utility belt, currently containing only a strongly-typed three-way ValidationResult enum, enabling user scripts to do custom validations on, say, response bodies (see updated seatrial.lua for usage example; manual pages are TODO)
• some initial lua stdlib unit tests, also demoing how to unit test our lua FFI in general
• with a few corner cases not implemented, the bulk of combinators and validators (certainly enough to start being useful; see attached screenshot for proof that, modulo a known issue examples/simpleish: 10th thread (random) times out reading response #2, the example pipeline now actually does what it says on the tin)
• various messaging plumbing to start surfacing more "wtf is going on?" answers to the end user
• begin documentation
• move from a standalone clippy GH Action to an actions-rs/ set of actions that will build and test the application for both amd64 and aarch64 (arm64) Linux, and will check style against rustfmt (plus still run clippy). this should be enough CI to automate regression testing, now that I've started adding unit tests here and there. it also resolves all style guide questions going forward, now that the application has more than one author 😃

refs #1

[pdpol]

Super nitty q - do you have strong opinions on was vs is prefix for boolean functions? I'm used to seeing is_ but as per usual my only real preference is to have a convention, regardless of what that convention is.

[klardotsh]

huh, I suppose I never gave this thought, but since the data isn't dead yet (bring out yer dead.....), is is probably more appropriate, even though the request happened in the past by the time it gets to this function