Journal-configurable texts should be translatable, not single-language

Several plugin settings let a journal replace a localised string with wording of its own. Each of them is stored as one plain string, so a multilingual journal has to pick a single language for readers of every locale — and the fallback it replaced was properly localised, so configuring the setting makes translation *worse*.

Affected today:

- **Heading for the availability statement** (`availabilityStatementHeading`) — replaces `plugins.generic.codecheck.dataSoftwareAvailability` on the article landing page.
- **Text shown instead of a badge** (`codecheckBadgeText`) — replaces `plugins.generic.codecheck.badge.textOnly` in the article sidebar and the issue table of contents.

Both are reader-facing text on published article pages, which is exactly where a journal's locale settings matter.

OJS supports this: settings can be stored per locale, and the settings form renders a field per supported locale (`{fbvElement type="text" multilingual=true}`), with `getLocalizedSetting()`-style reads on the display side. The plugin's own settings form is a Smarty/FBV form, so this is a question of storing an array keyed by locale and reading the right entry, not of new infrastructure.

Worth deciding as part of this:

- What to do with values already stored as a plain string — treat them as the primary locale's value, or leave them until re-saved.
- Whether a missing translation for the reader's locale falls back to the journal's primary locale or to the plugin's own localised default. The second keeps the page in the reader's language; the first keeps the journal's chosen wording.
- Whether any further settings should follow. These two are the reader-facing ones today, and new ones of this kind should be multilingual from the start.

See also #152, where both settings were added.

Start with the plugin settings form for availabilityStatementHeading and codecheckBadgeText, then trace their display-side reads on the article landing page, sidebar, and issue table of contents. Review OJS's multilingual FBV fields and getLocalizedSetting()-style access. Done means both settings support per-locale values, existing plain strings have a defined migration behavior, and missing-translation fallback behavior is decided and covered.

Written by the indexing model from the issue text.