Examples with named file inputs

[philrz]

Some docs such as the join tutorial rely heavily on named file inputs, since they need to be able to show them referenced in multiple file/from contexts within a single query.

Details

This comes up in other spots, but the join tutorial is indeed the best example of this. It uses the approach of defining the separate named file inputs:

https://github.com/brimdata/super/blob/8e86ac0ff4c9da6c278eb0ec9a8efba9f888c9d5/docs/tutorials/join.md?plain=1#L17-L24 https://github.com/brimdata/super/blob/8e86ac0ff4c9da6c278eb0ec9a8efba9f888c9d5/docs/tutorials/join.md?plain=1#L29-L34

Then these are referenced in the various examples to show how the same data is handled differently in the join variations for inner/left/right/etc.

https://github.com/brimdata/super/blob/8e86ac0ff4c9da6c278eb0ec9a8efba9f888c9d5/docs/tutorials/join.md?plain=1#L46-L51

Ideas

If we wanted to support this, perhaps the existing mdtest-input concept could be re-used, but I guess we'd just need some way for the mdtest-spq to know to expect its input from there and not from its normal static input section. Once that's possible, it seems like more of the heavy lifting would be on the Playground rendering side of things. I imagine there'd need to be some kind of new widget that shows the named input and its contents, perhaps giving the user the option to modify its contents much like we do currently with the input in the Playground example itself. Then I'm imagining there'd need to be some visual modification to the Input panel itself to make it obvious to the user that the input is coming from elsewhere. Finally, there'd need to be some kind of wiring so the Playground example does actually take its input from that alternate source when executing the query. Sounds like a lot! 😅