Delimiters in outputOf, map, reduce, etc. for #20

[wti]

This PR for #20 adds three kinds of delimiters:

• splitting input (segmentingInputAt)
• joining output that is combined into one string (withOutputSeparator)
• terminating output that is printed once per input (withOutputTerminator)

The commits should be in an order of likelihood you'd want them in case you want to pick some aspects. I started with the fix for #22 in case you wanted to adopt both at once.

Because the API's call each other, the parameters end up being viral (read: API pollution?), albeit ignorable as defaults. Most changes are inScript, where I believe you wanted only a simple API surface. But the ability to reduce text to objects in a parse pipeline is my primary goal, so I hope they're not too noisy. One commit adds docc to at least explain.

I chose longer names to try to be Swifty, but I can try to propose shorter ones (splitAt? endWith?).

All changes are intended to be source and behavior compatible using the existing defaults. The last commit uses a constant for the default newline to ensure it's consistent and to simplify auditing. Other "\n", e.g., in echo, are not converted because they stem from different semantics.

The main demo is just to hint the API to new users.

I'm happy to prune or polish as needed. Thanks!

[GeorgeLyon]

I agree that it’s suboptimal that these parameters are viral in all the API. I think step 1 would be to add the functionality to Shwift, and not change Script.

for Script, I’m thinking the API should just be splitInput(on separator: String) -> some AsyncSequence<String> then you can call the regular suite of Swift list comprehension functions on that value. So something like foo | splitInput(on: “\0”).compactMap(…) | bar.

[wti]

Sounds good!

Except I'm not sure how to do splitInput(on separator: String) -> some AsyncSequence<String>, or how to pipe it as suggested by splitInput(on: “\0”).... | bar.

The API can't return an AsyncSequence since Lines derives from stdin stream that would be closed when the API returns. Pipes can be chained by virtue of always progressing the same stdin/stdout FileDescriptor, but that stops once the input gets chunked into lines or types.

So I'll propose a minimal splitInput with a reducing operation taking String. Rather than unwinding most of the code this PR, I'll just open a new minimal one with that form of splitInput (Let me know if you prefer otherwise.)

[wti]

done in #26