Make `std` an optional dependency

[alilleybrinker]

Looking at the current API, I believe most of this crate could be made no-std compatible. The only parts used currently which require std are the std::io bits, so the question would be what API should/could be presented in no-std context.

It looks like moving the Read and Write traits into core is an eventual goal, currently blocked on the fact that std::io::Error involves boxing (and thus need alloc). The function on the Read and Write traits specify std::io::Error as the return type, so they can't move unless/until std::io::Error changes.

I'm doing some investigating on how people have dealt with this IO limitation in other contexts.

[alilleybrinker]

Note that this implies no-std-ness for all of our dependencies by default as well, with the std feature activating std-ness for those dependencies. I haven't yet evaluated whether our dependencies support this.

[alilleybrinker]

Looking at our deps, we have four first-level dependencies:

• hex: Has an optional std feature. Is no_std if that feature isn't turned on. It's on by default.
• sha1: Is itself unconditionally no_std. Has a std feature which turns on std for one of its own dependencies. Without that feature, entirely no_std-compatible.
• sha2: Same as sha1.
• url: Not at all no_std-compatible. If we're no_std, we'd need to turn this dependency off and deactivate our APIs that rely on it. There may be a no_std-compatible alternative; I haven't looked.

So that's three deps that are no_std-compatible, and one that isn't. The one that isn't could be turned off without much issue.

---

We should also look at our own use of std today, findable with this code search.

Item	no_std alternative available?	Can transition to core immediately?
std::any::Any	core::any::Any	YES
std::cell::RefCell	core::cell::RefCell	YES
std::collections::HashSet	Not in core or alloc	-
std::cmp::min	core::cmp::min	YES
std::error::Error	core::error::Error exists, but is behind an unstable feature flag (see this issue)	-
std::ffi::c_char	core::ffi::c_char	YES
std::ffi::c_int	core::ffi::c_int	YES
std::ffi::CStr	core::ffi::CStr	YES
std::ffi::CString	alloc::ffi::CString (not in core)	-
std::ffi:NulError	alloc::ffi::NulError (not in core)	-
std::fmt::Display	core::fmt::Display	YES
std::fmt::Formatter	core::fmt::Formatter	YES
std::fmt::Result	core::fmt::Result	YES
std::fs::File	Not in core or alloc	-
std::hash::Hash	core::hash::Hash	YES
std::io::BufReader	Not in core or alloc	-
std::io::Error	Not in core or alloc	-
std::io::Read	Not in core or alloc	-
std::io::Seek	Not in core or alloc	-
std::io::SeekFrom	Not in core or alloc	-
std::io::Write	Not in core or alloc	-
std::ops::Deref	core::ops::Deref	YES
std::ops::Not	core::ops::Not	YES
std::os::unix::prelude::FromRawFd	Not in core or alloc	-
std::os::unix::prelude::RawFd	Not in core or alloc	-
std::os::windows::io::FromRawHandle	Not in core or alloc	-
std::os::windows::prelude::RawHandle	Not in core or alloc	-
std::panic::catch_unwind	Not in core or alloc	-
std::panic::UnwindSafe	core::panic::UnwindSafe	YES
std::path::Path	Not in core or alloc	-
std::path::PathBuf	Not in core or alloc	-
std::ptr::null	core::ptr::null	YES
std::ptr::null_mut	core::ptr::null_mut	YES
std::result::Result	core::result::Result	YES
std::slice::from_raw_parts	core::slice::from_raw_parts	YES
std::slice::from_raw_parts_mut	core::slice::from_raw_parts_mut	YES
std::str::FromStr	core::str::FromStr	YES
std::str::Utf8Error	core::str::Utf8Error	YES

Based on this, we have a large number of std uses today which can be immediately switched to using the core equivalents (the std versions are just re-exports anyway, so this will not break anything).

For the remainder, some have equivalents in alloc, and some have no equivalent. The options there will be to:

• Conditionally remove APIs if no_std (or, more correctly, optionally include the APIs if the std feature is on, and have it on by default)
• Find no_std-compatible replacements (for example, maybe HashSet has a no_std-compatible alternative available somewhere).

---

Based on the above, we have the following checklist:

• Update the hex, sha1, and sha2 deps to turn off their default features and not re-enable the std feature, thus making them no_std.
• Make the url dep optional, only turned on if std is also turned on. Update the code using url to work with this new setup.
• Transition all core-compatible imports to use core instead of std.
• Investigate options for remaining std imports and make plan for how to handle them individually.

[alilleybrinker]

Finally done! In the end, after all the prior refactorings and improvements to the GitOid type, actually making the transition only took about an hour!

Next step will be making omnibor no_std-compatible.