buffer: Audit for panics and refactor

[kurtjd]

Removed panic paths from the buffer module. Instead made methods fallible and introduced an Error type.

Because certain traits are used with methods that assume infallibility (such as the drop and borrow traits), I couldn't just make these return a result. Instead, I added a Poisoned status so in the off chance that a drop or borrow call would have panicked originally, the buffer is marked poisoned and will return a Poisoned error on future accesses.

This also breaks the interfaces of a few services. For these I added a Buffer error and made methods fallible if necessary. I'm not a fan of this since any buffer errors represent an internal programming bug to the service and not something the user should expect/handle, and this breaks encapsulation. I do not want to silently just ignore buffer errors, so I'm not sure what other alternative there is here (open to suggestions).

Edit: Thinking about maybe renaming the Buffer error variant of these services to Internal or something. I'd prefer to make it more clear when an error represents an internal invariant being broken that is not something meant to be handled by the caller in any practical manner. It would act as a catchall since the specifics of what caused the error are implementation details that could change any time and not something the caller should be concerned with.

Also introduced a Never type alias which is useful now that some functions represent never-ending tasks which should never return unless there is an error (see related discussion: #634 (comment)).

Resolves #659

[jerrysxie]

@kurtjd Don't forget to announce on Zulip once it is ready to be merged, thanks!

[jerrysxie]

Bypassed policy and merge since people are on vacation.

[kurtjd]

Zulip announcement: https://opendevicepartnership.zulipchat.com/#narrow/channel/495405-embedded-controller/topic/embedded-services.20buffer.20breaking.20changes/with/565229931