Add Fuel Gauge driver to zephyr::device

[bjackson312006]

This PR adds a zephyr::device::fuel_gauge module (located at zephyr/src/fuel_gauge.rs) that implements a safe Rust wrapper around the Zephyr fuel gauge API. This PR also adds a simple fuel_gauge sample to demonstrate this driver.

Since Zephyr's fuel gauge API is based around the fuel_gauge_prop_val union, this driver was designed to expose all the same data but via explicit accessors for each field/property. The C fuel_gauge_prop_t type was adapted into pub(crate) enum FuelGaugeProp and pub(crate) enum FuelGaugeBufferProp, which are meant to provide some internal type safety for the rest of the driver. These enums map directly to the autogenerated crate::raw::fuel_gauge_prop_type module. This involves some annoying boilerplate, but it's worth it so the raw C constants can be contained in one place without needing to be used internally by the rest of the driver. Plus, these enums will never need changes as long as Zephyr's API stays stable.
^^ Note: The depreciated constants in crate::raw::fuel_gauge_prop_type were deliberately left out of these enums.

Below this, there are some internal helpers used to wrap around the raw Zephyr calls: pub(crate) fn get_prop(), pub(crate) fn set_prop(), and pub(crate) fn get_buffer_prop(). These helpers are meant to isolate the main unsafe blocks in the driver, and allow the rest of the driver to use the safe FuelGaugeProp and FuelGaugeBufferProp types when requesting data. TLDR they provide safer internal wrappers for the raw fuel_gauge_get_prop(), fuel_gauge_set_prop(), and fuel_gauge_get_buffer_prop() calls to the C API.

After that, there's the ManufacturerName, DeviceName, and DeviceChemistry types, which each wrap around a heapless::String. This adds a dependency (heapless), but significantly improves the interface of the user-facing manufacturer_name(), device_name(), and device_chemistry() functions since users no longer need to manually pass in a mut buffer for the calls to write into. Plus, a String is a more accurate way to type this data (compared to &mut [u8]) and works better with Debug/Display/fmt.

Below that is the main public API, which first includes is_ready() and the aforementioned manufacturer_name(), device_name(), and device_chemistry() functions used to read buffer props. The functions after that, which make up the vast majority of the public API, are the getters and setters for the single-value union properties. These functions all follow an identical structure: They call the safe get_prop()/set_prop() helpers for their respective FuelGaugeProp, and then access the returned union prop in a small unsafe block. I looked into moving these unsafe blocks directly into get_prop() and set_prop(), but this wasn't possible to do without defeating the purpose of the moves in the first place. However, since these blocks are all tiny, identical, and performing an action we know to be safe (union operations guaranteed to valid per the calls to the Zephyr API), I think this is fine.
^^ Note: Not all of the getters have setters since a lot of the fields are only meant to be read

There's no single property to match on for a fuel gauge as far as I know, so I'm just matching on a single property ("sbs,sbs-gauge-new-api") like flash-controller does. This should be fine for SBS-compatible fuel gauges, but down the line it may be necessary to explore some other way to automatically make this work for all fuel gauges.

Aside that, the new fuel_gauge sample shows how to use the driver by periodically reading a bunch of data from the gauge and logging it. The logging is made easy since all types returned by the driver derive Debug, including ManufacturerName, DeviceName, and DeviceChemistry.

[kurtjd]

Overall, very good, though a few things I think are worth addressing.