feat: add from_utf8_lossy

[llvm-x86]

This function attempts to directly convert the byte slice into a SmolStr,
leveraging its inline storage for small results to avoid heap allocations.
For larger inputs or when the converted string (with replacements) exceeds
the inline capacity, it falls back to a heap-allocated SmolStr.

Performance

This native implementation of from_utf8_lossy aims to optimize for SmolStr's
unique characteristics, particularly its inline storage. The performance relative
to String::from_utf8_lossy varies significantly based on input size and validity.

Key Trade-off: SmolStr cannot achieve zero-copy for small, valid borrowed
byte slices like String can (via Cow::Borrowed). SmolStr must copy the bytes
into its internal inline buffer for transient inputs, which introduces overhead.

Benchmarks (for INLINE_CAP=23):

 | Scenario                    | SmolStr (ns) | String (ns) | Comparison                               |
 | :-------------------------- | :----------- | :---------- | :--------------------------------------- |
 | Small Valid UTF-8 (len=12)  | ~14          | ~11         | ~27% slower (due to mandatory copy)      |
 | Small Invalid UTF-8 (len=12)| ~15          | ~26         | ~42% faster (avoids String's heap alloc) |
 | Large Valid UTF-8 (len=1000)| ~49          | ~224        | ~78% faster (efficient `Arc<str>` conv)  |
 | Large Invalid UTF-8 (len=1000)| ~1.29 µs     | ~1.15 µs    | ~12% slower (String's optimized heap path) |

Summary:

• SmolStr is significantly faster for small, invalid UTF-8 strings because it avoids
  String's heap allocation for Cow::Owned results.
• SmolStr is significantly faster for large, valid UTF-8 strings due to the efficiency
  of converting a &str directly into an Arc<str> for heap storage.
• SmolStr is slower for small, valid UTF-8 strings because it must copy the bytes
  into its inline buffer, whereas String can return a zero-copy Cow::Borrowed.
• SmolStr is generally slower for medium to large, invalid UTF-8 strings, as String::from_utf8_lossy
  has a highly optimized heap-based replacement logic that outperforms SmolStr's current approach
  for these scenarios.