Update #[inline] documentation

[ppershing]

As of rust-lang/rust#116505 the cross-crate inlining can happen even without explicit #[inline] attribute in simple-enough cases. I suggest we update the wording in the inline section to account for this

[nnethercote]

Here is the existing description:

• None. The compiler will decide itself if the function should be inlined. This will depend on factors such as the optimization level and the size of the function. Non-generic functions will never be inlined across crate boundaries unless link-time optimization is used; generic functions might be.
• #[inline]. This suggests that the function should be inlined, including across crate boundaries.
• #[inline(always)]. This strongly suggests that the function should be inlined, including across crate boundaries.
• #[inline(never)]. This strongly suggests that the function should not be inlined.

Here is a draft rewrite:

• None. The compiler will decide itself if the function should be inlined. This will depend on factors such as the optimization level, the size of the function, whether the function is generic, and if the inlining is across a crate boundary.
• #[inline]. This suggests that the function should be inlined.
• #[inline(always)]. This strongly suggests that the function should be inlined.
• #[inline(never)]. This strongly suggests that the function should not be inlined.

What do you think?

[ppershing]

Your suggestion is certainly fine. Even better - but I am not sure how much details perf-book wants to maintain - would be to clarify pre/post rust 1.75 state (especially given that this is a recent change and some fols might still be on older versions of rust).

[nnethercote]

I chose to slightly reduce the level of detail so that it's correct for both pre- and post-1.75. Thanks again.