feat/chore: introduce fallible alternatives for MutableBuffer

[Rich-T-kid]

Which issue does this PR close?

• works towards [arrow-buffer] Add fallible APIs for overflow-prone buffer growth #9843.
• a follow PR will be made to wire up the fallible API into other portions of the code base.

Rationale for this change

see #9843.
MutableBuffer is a low-level building block used throughout the Arrow implementation. Every growth operation, reserve, resize, push, extend_from_slice, etc, can panic on arithmetic overflow or an invalid allocation layout. In library code that needs to surface errors gracefully. This PR adds methods to return errors instead of panicking.

I made new methods instead of adding conditional checks/wrappers for each method because its easier to slowly roll these changes out to call sites instead of swapping.

What changes are included in this PR?

┌──────────────────────────┬──────────────────────┐
│         Fallible         │      Infallible      │
├──────────────────────────┼──────────────────────┤
│ try_reserve              │ reserve              │
├──────────────────────────┼──────────────────────┤
│ try_repeat_slice_n_times │ repeat_slice_n_times │
├──────────────────────────┼──────────────────────┤
│ try_reallocate (private) │ reallocate           │
├──────────────────────────┼──────────────────────┤
│ try_resize               │ resize               │
├──────────────────────────┼──────────────────────┤
│ try_shrink_to_fit        │ shrink_to_fit        │
├──────────────────────────┼──────────────────────┤
│ try_extend_from_slice    │ extend_from_slice    │
├──────────────────────────┼──────────────────────┤
│ try_push                 │ push                 │
├──────────────────────────┼──────────────────────┤
│ try_extend_zeros         │ extend_zeros         │
└──────────────────────────┴──────────────────────┘

Are these changes tested?

Currently these methods aren't wired up to anything in the code base so I didn't include any test. Id be happy to include some. The implementations of the fallible API's are 1-1 to their non-fallible counter parts so i'm not sure if this would be needed.

Are there any user-facing changes?

yes, users can now work with errors instead of having their programs panic.

[Rich-T-kid]

I made new methods instead of adding conditional checks/wrappers for each method because its easier to slowly roll these changes out to call sites instead of swapping.

once this is merged Ill work on updating call sites. From my understanding this isn't always a 1-1 switch, its only possible to use the fallible alternative if the calling functions also returns an error