Create a mock for gettext-rs in order to fix the failing build on macos

[kellpossible]

A temporary fix for failing build on macos https://github.com/rustcoreutils/posixutils-rs/actions/runs/10173778299/job/28138428272 which is highly likely to be related to gettext-rs/gettext-rs#121

A long term resolution will likely involve one of the following:

a) Wait for gettext-rs/gettext-rs#119 to get merged, and then fix the breaking changes introduced by dennisschagt/gettext-rs@ec1aad1
b) Use https://docs.rs/gettext/0.4.0/gettext/ instead accepting its limitations and it's apparent abandonment.
c) Fork gettext-rs.
d) Replace gettext entirely with a more modern localization system. https://github.com/unicode-org/message-format-wg is still in the works, and so something based on https://github.com/projectfluent/fluent-rs seems likely to be the best option. My biased opinion (maintainer of the project) is that https://docs.rs/i18n-embed/latest/i18n_embed/ along with https://docs.rs/i18n-embed-fl/latest/i18n_embed_fl/macro.fl.html could be a good option for doing this in an established pattern, and would be willing to put in the time to pare down any dependencies and add any small features necessary to make it work for this project.
e) Roll our own very limited localization system to keep dependencies to a minimum. If accessibility really is a priority I don't see this being a great option, it also makes external tooling around localization more limited.

[kellpossible]

Some other thoughts:

• Many of these binaries may share common error messages, so it would be good if they can load localizations from shared resource files.
• If we want to publish the binaries here to crates.io, then ideally the binaries built using cargo install can embed all the required localization resources.
• Perhaps these two modes of operation can be controlled using a compile time feature flag.