This implementation has been compiled with the [pigweed toolchain](https://pigweed.dev/toolchain.html) and tested on:
 - Raspberry Pi Pico 2 with the following options\
`--target=armv8m.main-none-eabi`
`-march=armv8m.main+fp+dsp`
`-mcpu=cortex-m33` 
 - Raspberry Pi Pico with the following options\
`--target=armv6m-none-eabi`
`-march=armv6m`
`-mcpu=cortex-m0+` 

They both compile down to a little bit more than 200 bytes and are between 2 and 10 times faster than byte per byte copies.

For best performance the following options can be set in the `libc/config/baremetal/arm/config.json`
```
{
  "codegen": {
    "LIBC_CONF_KEEP_FRAME_POINTER": {
      "value": false
    }
  },
  "general": {
    "LIBC_ADD_NULL_CHECKS": {
      "value": false
    }
  }
}
```

Previously setting LIBC_COPT_STRING_UNSAFE_WIDE_READ would cause a build
error because there is a path in the ifdef that doesn't return anything.

The previous implementations called other entrypoints. This patch fixes
strcat, strncat, and stpcpy to be properly independent.

This is the first step in preparation for:
https://discourse.llvm.org/t/rfc-make-clang-builtin-math-functions-constexpr-with-llvm-libc-to-support-c-23-constexpr-math-functions/86450

The string_utils.h file previously included both memcpy and bzero. There
were no uses of bzero, and only one use of memcpy which was replaced
with __builtin_memcpy.

Also fix strsep which was broken by this change, fix a useless assert of
"sizeof(char) == sizeof(cpp::byte)", and update the bazel.

Fixes #111546

---------

Co-authored-by: alyyelashram <150528548+alyyelashram@users.noreply.github.com>

Add conditional compilation to add support for AArch64 without vector
registers and/or hardware FPUs by using the generic implementation.

**Context:**

A few functions were hard-coded to use vector registers/hardware FPUs.
This meant that libc would not compile on architectures that did not
support these features. This fix falls back on the generic
implementation if a feature is not supported.

Summary:
Right now a lot of the memory functions error if we don't have specific
handling for them. This is weird because we have a generic
implementation that should just be used whenever someone hasn't written
a more optimized version. This allows us to use the `libc` headers with
more architectures from the `shared/` directory without worrying about
it breaking.