feat(interpreter): add more helper methods to memory

[DaniPopes]

These would be useful in Foundry.
Second commit reduces usage of inline always since it's almost always unnecessary, and sometimes can hinder performance when normal inline hint is enough.
In release mode in our case performance is the same.

[rakita]

Suggested change

	/// Panics on out of bounds.
	/// # Panics
	///
	/// Panics on out of bounds.

[rakita]

Suggested change

	/// Panics on out of bounds.
	/// # Panics
	///
	/// Panics on out of bounds.

[rakita]

Suggested change

	/// Panics on out of bounds.
	/// # Panics
	///
	/// Panics on out of bounds.

[rakita]

Suggested change

	/// Panics on out of bounds.
	/// # Panics
	///
	/// Panics on out of bounds.

[rakita]

Suggested change

	/// Panics on out of bounds.
	/// # Panics
	///
	/// Panics on out of bounds.

[rakita]

Jsut to talk about this a little:
General topic of inlining: https://matklad.github.io/2021/07/09/inline-in-rust.html

https://indico.cern.ch/event/386232/sessions/159923/attachments/771039/1057534/always_inline_performance.pdf
This slide from 2015 says that:
for Intel compiler inline is faster than others modifiers (or combination), On the worst case, inline is similar to always_inline
For GCC always_inline with 10M is usually faster than other modifiers, in worst case, always_inline is similar to inline

We do have LTO set to true.

It seems that the thing with inlining is to always measure