consider adding a `RangeError` type

[BurntSushi]

In pursuit of working on #373, I've realized that the vast majority of APIs on the civil datetime types can be written in const Rust. This used to be quite difficult because of Jiff's use of ranged integers internally. But now that those are gone that opens the door to making more of Jiff's API const.

However, there is one remaining blocker I think: the use of the Error type. It is very difficult to usefully have an Error for a const API. Internally, creating an Error does an allocation to support error chaining:

jiff/src/error/mod.rs

Lines 495 to 506 in 76f2a9e

	impl From<ErrorKind> for Error {
	fn from(kind: ErrorKind) -> Error {
	#[cfg(feature = "alloc")]
	{
	Error { inner: Some(Arc::new(ErrorInner { kind, cause: None })) }
	}
	#[cfg(not(feature = "alloc"))]
	{
	Error { inner: Some(Arc::new(ErrorInner { kind })) }
	}
	}
	}

That in turn makes creating Error values impossible in const in today's Rust. And I don't think that's going to change any time soon.

So we either need to make Error more const friendly (which seems difficult while preserving chaining) or make fallible const APIs return a new simpler error type that implements Copy, is small and has no issues being created in a const context.

I think most fallible APIs in jiff::civil can use this new simpler error type. The main exception are APIs involving rounding, which would unfortunately include, e.g., Date::checked_add. But I think the API could otherwise be const? Not sure, so it might be worth digging into that a bit.

APIs on Zoned could also probably return a RangeError. But whether those can be const or not isn't clear to me, since that would require all TimeZone operations to be const. That could be challenging, and in particular, because TimeZone uses pointer tagging internally.

We can add a impl From<jiff::RangeError> for jiff::Error trait impl to make error composition easy.