Issue #3615004: Move API credentials out of exported configuration

The hashing slug and the login/token pairs lived in myrest.auth_settings. Anything in a configuration object is written out by a configuration export and normally ends up in version control, so the API secrets were committed alongside the site configuration.

• Add myrest.credential_store, backed by MyrestCredentialStoreInterface. The slug resolves from the Key module, then state, then the legacy configuration; login/token pairs resolve from state, then the legacy configuration. Existing sites therefore keep authenticating with no intervention.
• MyrestTokenAuthProvider reads credentials from the store.
• The settings form writes secrets to state and migrates any legacy configuration values on save, then clears them from the config object. The slug is a password field, stored tokens render as ******** and are restored on save unless the administrator edits them, and a warning is shown while secrets are still in configuration.
• Optional Key module integration via the new slug_key_id setting. A selected key wins over the value in state.
• secure_slug and users_tokens remain in the schema, marked deprecated and read only as a fallback.
• Document secret storage, the Key option and the upgrade path in README.

Also fixed, both found while doing the work:

• Remove MyrestSync1cRestGenerator. It referenced MyrestTokenAuthProvider::TOKEN and ::USERS_TOKENS, constants removed when token auth was reworked, so instantiating it was a fatal "undefined constant". It also extended Sync1cResourceBase, which does not exist anywhere in the codebase. On top of that its description printed the live API token and the API user names into the generated OpenAPI documentation, which is readable by anyone holding "access openapi api docs".
• MyrestLogSettingsForm had a @param tag on its class docblock and untranslatable #options for the hashing algorithm.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Closes #3615004