Publish the assert_prints spec helper

[HertzDevil]

This does not expose string_build_via_utf16 because it was only needed by spec/manual/string_normalize_spec.cr to define a helper similar to assert_prints that uses a custom expectation; instead, assert_prints itself is overloaded to accept expectations that are not eq.

[straight-shoota]

I think exposing this is a good idea. User code will need to do similar specs as stdlib.

I'm not sure about the should overload, though. Is it really useful? It seems tailored to an exotic use case which would not be made much use of outside of stdlib.

[HertzDevil]

The expectation could also be match or contain, I don't think they are that rare in specs. But more than that we shouldn't encourage people to copy the body of assert_prints and swap out just the expectation if they do need one that isn't eq

[HertzDevil]

This is a tough one. #13539 means that the IO overloads use eq(%str.scrub) and the other ones use eq(%str). Thus there is no longer a single expectation used throughout assert_prints.

Specs outside String itself should never have to deal with invalid encodings, so I think we should revert the scrub added there and express those specs in some other way.