Aggressive inlining (+20% serialization speed boost)

[hoxxep]

This PR adds a roughly 20% speed improvement to serialization in my application benchmarks.

The use of #[inline(always)] is required because LLVM sees the function as "large" and avoids inlining a plain #[inline] hint. However, almost all usage of these methods in ciborium specify the enum at compile-time, which means this "large" function can be optimised to a small set of instructions and remove many branches.

I could add a ciborium-bench crate into the workspace using criterion to demonstrate this if this change is likely to be accepted? Cheers!

---

One minor concern is compiling with opt_level s or z, where application developers may prefer a smaller bundle size (such as WASM use cases). We could use a smaller-bundle feature flag for this case, and use #[cfg_attr(not(feature = "smaller-bundle"), inline(always)] instead. The binary bloat is likely minor though.

[rjzak]

What's the size increase? Maybe gate the inlining by feature or not Wasm?
Edit: maybe it doesn't matter since there's a lot of inlining anyway.

[npmccallum]

I'm very happy to have more aggressive inlining. I'm not worried about code size. If people complain, we can solve the problem then.

My biggest question is: should we be even more aggressive?

[rjzak]

LGTM. I can merge, or wait for further inlining.

[hoxxep]

Perhaps merge this for now and we can investigate further inlining later?

I found inline always on the Header/Title deserialization methods had little effect and might need more of a refactor to achieve a similar improvement.

I haven't checked the WASM bundle size but agree with the rationale (and reckon it's a minor effect anyway). It might be worth adding criterion benchmarks into this repo though.