Eliminate need for time-macros crate

[jhpratt]

The time-macros crate currently provides macros for statically-known values. With the stabilization of proc_macro_hygiene in Rust 1.46, a second crate is no longer needed solely to hack around compiler limitations. However, there are still some restrictions that prevent these macros from becoming declarative macros, rather than the current procedural macros. This would simplify the code, as it wouldn't be necessary to duplicate code across crates. Additionally, the macros could be used internally and could exist without the need of a feature flag, as the compile-time impact would be minimal.

The offset! macro can be implemented relatively easily on stable today, as advanced features are not needed and the range of valid integers is small. The snippet below relies on const_panic, as it appears to be progressing towards stabilization; this dependency can be removed for the offset! macro without much effort.

The time! macro is a bit trickier, as handling the subsecond values requires additional effort. While floating point methods are not even unstably const, basic arithmetic is stably const. Because the floating point literal cannot be trivially matched in a macro_rules!, const_panic is a dependency for porting the time! macro, which would allow static verification of the value.

The date! macro could conceivably be implemented as macro_rules! on stable, but doing so would be infeasible (both to the author and the compiler). As the range of valid years is significant, the number of macro matchers would be in the tens of thousands (or multiple million if the large-dates flag is enabled). With the stabilization of const_panic, the date! macro should be able to be implemented without issue. The macro below does not include week-based dates, as it isn't possible to use the same syntax in macro_rules!.

The format_description! macro is by far the most challenging. As a non-exhaustive list, const destructors, const allocation, const trait implementations, and the stabilization of a number of stdlib methods as const. This is undoubtedly a long ways off, so it's not particularly worth going into a ton of detail here.

---

This snippet currently relies on the const_panic feature. Note that this is only a proof-of-concept and has not been thoroughly tested; it is not what currently backs the time crate. Having rust-lang/rust#59368 would be useful to (publicly) keep the macros in the existing macros module.

[jhpratt]

Given that proc macros can control where the error message points to, even on stable, there are definitive advantages to keeping it this way. When proc_macro_diagnostics is stabilized, this situation will only be improved. As a result, I feel this is the best way forward.