Fix SVE dynamic dispatch ODR violation

[AntoinePrv]

Bug found when adding dynamic dispatch with both SVE128 and SVE256.
The issue is found was on:

svbool_t sve_ptrue() noexcept { return sve_ptrue_impl(index<sizeof(T)> {}); }

Without XSIMD_INLINE, in debug mode, two inline symbols were created and the linker picked
one (the one with -msve-vector-length=16) and applied it everywhere.

What changed:

• xsimd_inline.hpp was renamed xsimd_macros.hpp to extend it with other macros required here.
• This PR applied XSIMD_INLINE liberally, but because this is fragile, it also adds an
  inline namespace to SVE to prevent future (and unfound) violations.
• Working with inline namespace is more tricky than I thought, so I had to rename all
  detail to detail_sve inside the header to avoid confusion.

Notes:

• ⚠️ This is an ABI break
• I haven't yet applied the formatter as doing so will make it hard to review (I'll do
  it right before merging when there is a approval).
• I will send a similar PR for RVV which potentailly suffers from the same issue.

@serge-sans-paille @JohanMabille

[JohanMabille]

Working with inline namespace is more tricky than I thought, so I had to rename all
detail to detail_sve inside the header to avoid confusion.

Can you elaborate a bit more about this?

[AntoinePrv]

@JohanMabille, well in other files there are public utilities in namespacexsimd::kernel::detail.
In sve, they would be in xsimd::kernel::(sve128)::detail.
So with sve code invoking detail::something the compiler gets all confused and complains that something is not in xsimd::kernel::sve128::detail, without looking in xsimd::kernel::detail.
I tried all the using and full qualification I could, with no success. Best I could do is to explicitly name them differently.

Alternatively, we should say that anything in detail is header-private, and move the library-internal ones to xsimd::kernel::utils or something.

[JohanMabille]

Thanks for the detailed explanation. I think this one can be merged once the formatting is fixed.