Improve profile role membership UX and harden stale form/session handling

[Rvice]

Summary

Improves the profile role membership experience by replacing disruptive reloads with inline updates, preserving in-progress edits more reliably, and fixing several stale token/session edge cases uncovered during testing.

Highlights

• Update role membership rows inline instead of reloading the full section for common edit and delete actions.
• Move memberships between Current, Former, and Future sections in place when date changes reclassify them.
• Keep membership dates, duration badges, and section visibility in sync after inline changes.
• Refresh profile memberships after changes made in the Change Role Memberships modal.
• Fix checkbox autosave in the modal after a client-side path regression.
• Harden membership and login flows against stale form/session state.

User-facing improvements

• Removing a role membership no longer reloads the full role memberships area.
• Editing membership dates updates the visible row immediately when possible.
• Memberships that become former or future memberships move into the correct section without a full refresh.
• Former and Future sections are shown or hidden correctly when memberships move.
• Date displays continue to follow the configured system date format.
• Other unsaved inline membership edits are preserved more reliably during fallback reloads.

Stability fixes

• Added fallback CSRF handling for inline membership forms and modal-driven membership changes.
• Improved stale form handling for profile membership updates.
• Prevented a stale login form/session mismatch from causing a fatal error after redirecting to login.

Internal cleanup

• Moved profile membership helper logic out of the PHP-generated script block into shared profile JavaScript.
• Replaced packed row-sort metadata with explicit sortable fields and a clearer client-side comparator.

Testing

Validated with targeted syntax checks on the touched PHP files, including mirrored deployment copies where applicable.

[Fasse]

Thanks for your work to improve Admidio.
This merge request is very big. To better check a merge request it would be better if you can split it to each feature. With this big merge request it's not possible to do a good review because I don't understand which line of code belongs to which features.

So it would be more helpful to create a small merge request that belongs to one bulletpoint of your list.

[Fasse]

Also translations must not be available in all languages. It should only provided in english. The translations will than be handled at our translation platform transifex.

[Rvice]

Thanks for your work to improve Admidio. This merge request is very big. To better check a merge request it would be better if you can split it to each feature. With this big merge request it's not possible to do a good review because I don't understand which line of code belongs to which features.

So it would be more helpful to create a small merge request that belongs to one bulletpoint of your list.

The full path of this is around edits not saving and the user having no visual of that. Sometimes it saves, sometimes it doesn't. It was a lot of back and forth testing as it grew. It definitely got legs and needs a thorough understanding of all the changes.

Maybe I can have smaller PRs:

1. Changes just for indication save is in progress, didn't work or did
2. CSFR updates
3. Full refresh vs section refresh