utf8proc: add new package

[betonmischer86]

📦 Package Details

Maintainer: @
_{(You can find this by checking the history of the package Makefile.)}

Description:
utf8proc is a small, clean C library that provides Unicode normalization, case-folding, and other operations for data in the UTF-8 encoding.

---

🧪 Run Testing Details

• OpenWrt Version: OpenWrt SNAPSHOT r31813
• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: Banana Pi BPI-R4 (2x SFP+)

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

If your PR contains a patch:

• It can be applied using git am
• It has been refreshed to avoid offsets, fuzzes, etc., using

  make package/<your-package>/refresh V=s

• It is structured in a way that it is potentially upstreamable
  _{(e.g., subject line, commit description, etc.)
  We must try to upstream patches to reduce maintenance burden.}

[GeorgeSapkin]

Unless something is going to depend on this library, and nothing indicates this in either the PR or commit message, there's no point adding it.

As with the other PRs, you need to set yourself as the maintainer and don't need to include the license file.

[betonmischer86]

As with the other PRs, you need to set yourself as the maintainer and don't need to include the license file.

Done.

Unless something is going to depend on this library, and nothing indicates this in either the PR or commit message, there's no point adding it.

I ported utf8proc (and unibilium, #27951) as build-time dependencies of Neovim before hitting a roadblock with Neovim itself. At some point, the Neovim build process starts running its own compiled code, including the actual nvim binary. So in order to cross-compile Neovim for OpenWrt, I would first need to build it (and all of the dependencies) as a host package to bootstrap the target build. Let me know whether a complicated build sequence like this would be accepted. If it's fine, should I hold off with utf8proc and unibilium PRs until the Neovim package is ready?

Also, utf8proc is already used by subversion as a bundled dependency. Perhaps the maintainer (@krant) would consider using a separate package instead.