Remove flatten_version utility and related logic

[enricobattocchi]

Context

The Block editor button translations were not working after bumping the version to 4.6-RC1. The issue was caused by how WordPress resolves script translation files from WP.org.

When wp_set_script_translations() is called, WordPress computes an MD5 hash from the relative file path of the registered script to look up the corresponding JSON translation file on WP.org. Previously, script filenames included a flattened version number (e.g., duplicate-post-edit-450.js for v4.5), but the flattening logic failed with pre-release suffixes, producing incorrect filenames like duplicate-post-edit-46-RC1.js. This caused the translation file hash to not match any existing translations on WP.org.

Summary

This PR can be summarized in the following changelog entry:

• Drops the version number from the JS file names.

Relevant technical choices:

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Smoke test that the JS features (buttons added to the block editor, Quick edit checkbox, tabs in the Settings, etc.) are working.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Plus the translations for the buttons in the Block editor should be working.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unittests to verify the code works as intended

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label and noted the work hours.

Fixes #