Make NaiveTime::from_str support HH:MM as well as HH:MM:SS

[jamespharaoh]

Times are commonly written without seconds, NaiveTime::from_str should recognise this format as well. This adds that functionality.

This makes parsing data structures which include times easier, since you would otherwise need to specify a format string or construct the NaiveTime yourself.

[esheppa]

Thanks for this @jamespharaoh - apologies for the long delay. I like where you are going with this as it would be interesting to make the various FromStr implementations more flexible, however there are some tradeoffs which I'd like to seek comment on before going ahead with this:

a) Parse/Display Roundtrip - if we allow multiple valid input formats, then it is impossible guarantee a identity when combining parse and display. (This may also be the case currently, which we could fix instead if desired)
b) How we view the FromStr and Display impls compared to the format and parse_from_str methods. For now the FromStr and Display impls have some sensible defaults, but it could be interesting to have FromStr try a couple of different common patterns in order (hopefully in an unambiguous way) to make parsing common date/time formats easier (especially for new users of the library) at the cost of some performance.

This PR falls within the latter option and if it is decided to go down that path, it might be interesting to have an array of arrays of Item<'static> and then try each one in order - this would also avoid adding the Truncated variant to Item.

[djc]

a) Parse/Display Roundtrip - if we allow multiple valid input formats, then it is impossible guarantee a identity when combining parse and display. (This may also be the case currently, which we could fix instead if desired)

At least for this case, I think parsing HH:MM as if it was written as HH::MM::00 makes sense. The identity round trip through Display doesn't seem very important to me at least in this case where there is a sensible default we can fill in.

[esheppa]

Thanks for the feedback @djc. In this case, if possible @jamespharaoh - would you mind implementing this using an array or arrays of Item<'static>? My line of thinking here is opening the way to allow for example 1500 to parse as a time as well in future. (Or alternatively, if we can make a case of Item::Truncated being generally useful, then maybe keep it as is)

[pitdicker]

Closing in favor of #1181.