Improvements to embedding api to allow making your own 'screen'

[plutonium-239]

I was trying to embed moor into my own application when I realized that I couldn't actually have moor run in a 60% width preview window and it would have to be a separate screen.

One considered solution was to maintain a fork twin that can accept an input height/width, but I'm not sure if that would be useful upstream - since moor does not have such a use case.

So, this PR does two things that allow embedding, if that is a desirable thing:

1. Add PageFromStreamWithScreen for embedded paging

Extract the shared pager setup from pageFromReader into pageFromReaderWithScreen, which accepts a caller-provided twin.Screen instead of calling twin.NewScreen(). Add PageFromStreamWithScreen as a public entry point that skips the term.IsTerminal guard and delegates to the shared implementation.

This enables embedding moor inside another TUI (e.g. a bubbletea app) without moor taking over the whole terminal. The caller implements twin.Screen to render into a sub-region and feed events from the host TUI's event loop.

2. Add event constructors for embedding applications

Add NewEventRune, NewEventKeyCode, and NewEventMouse so that embedding applications can create twin events to feed into a custom Screen's event channel. Without these, the unexported fields on EventRune, EventKeyCode, and EventMouse make it impossible for external code to construct events.

Another solution if you do not want more exported functions is to export the struct fields themselves.

---

AI Disclosure

💘 Generated with Crush
Assisted-by: Crush:z-ai/glm-5.2

[walles]

Interesting!

Did you try to embed this exact version of moor in your app?

Real life data is super valuable here, changing public APIs after the fact is messy.

[plutonium-239]

Yes! I'm using it locally with go's replace directive, and these were all the changes required to build something like this:

moor is running interactively on the right side! With all its search/filtering functionality working.