Support any Display, not just &str

[epage]

This is split out of #13 (comment)

Input text doesn't have to be &str; it can be anything that can implement Display. This is especially useful when the origin source #12 (comment), so the intermediate allocation doesn't have to happen. Playing with take-two I think this dyn has negligible effect on runtime, the real killer to my time is dyn indirection to the span resolvers IIUC.

[epage]

I think this would actually hurt performance because we can't directly Display into a location but generally need to do calculations on it, so we'd need to do to_string(), even if its a &str, meaning we'll do more allocations.

[epage]

Since we'd have to take a &dyn Display and to_string() it anyways, I feel this isn't offering us much and am going to go ahead and close this. If there is a reason we should re-visit this, let us know!