Make TryCmd constructable by end-users

[indygreg]

(Filing this issue in response to discussion on #214.)

As I made the case for in #214, there is value in leveraging trycmd's internal data structures (namely TryCmd and everything its fields reference) to build your own process based snapshot testing library or to bend trycmd to your will. If you could construct TryCmd instances manually (bypassing the file loaders that are forced onto us today), this would create opportunities for customers to experiment with different file formats and different ways of constructing test cases. It would enable customers to leverage the test running functionality in the trycmd crate without having to reinvent that wheel. i.e. I think it would increase the overall value of the trycmd crate.

The code changes for this are minimal (77e05d7). I suspect the real debate is what the crate API surface area should be. Obviously sprinkling pub everywhere has semver and API support implications.

[epage]

Before getting into how to solve this, can we focus on the use cases? We offer snapbox as a lower level snapshotting library. What is it you are trying to accomplish that the current structure of trycmd and snapbox are getting in your way?

[indygreg]

I don't want to have to build my own runner (with steps), diffing functionality, etc.

I agree that snapbox is a useful foundational crate to have. But there's just enough functionality missing that I wanted to reach for trycmd's abstractions instead of reinventing the wheel.