Support datetime-local time parsing

[stephendolan]

This PR intends to close #602.

You can read more about DateTime Local inputs at this link:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local

From what I can gather, browsers basically use RFC 3339 without the timezone. Because of this, our Time::Format::RFC_3339 parser wasn't actually extracting the time element from a datetime-local input type in Lucky.

PR Components

• [TimeExtensions#parse] Add a custom Time::Format that will parse these datetime-local inputs correctly, though it will always use Time::Location.local for the timezone.
• [Specs] Moved the hardcoded strings to use time formatting where possible so that we can test more date/time ranges and check specific time values more easily.
• [Specs] Add some checks on specific parsed time components so that we can be more confident in the future that we're not missing components of the time.
• [Specs] Removed a test scenario for space_separated_yaml. Best I can tell, that was added here without any additional details, but it has never actually worked since we didn't have a formatter that matched down to the time element. Without a clear user story, I didn't feel confident adding a custom parser that would allow the new test validations to pass for that format.

[matthewmcgarvey]

Nice work on this 🎉🎉🎉

[jwoertink]

I have to dig in more later, but this PR breaks specs for me locally:

Failures:

  1) Time column type .parse casts various formats successfully
     Failure/Error: "#{result.value.hour} #{_format}".should eq("#{time.hour} #{_format}")

       Expected: "8 iso8601"
            got: "16 iso8601"

     # spec/type_extensions/time_spec.cr:25

I added some debugging to the spec to see which time format is breaking. I don't want to open an issue just yet since I'm not sure if this is only me, but I'm running these locally on my mac (Catalina 10.15.7), and not in Docker. Also, I'm in PST timezone.