Remove legacy user information options from system report data

[dotance]

Description

LLMS_Data::get_llms_settings() read fourteen legacy options into the system report and tracker payload:

• lifterlms_user_info_field_{names,address,phone,email_confirmation}_{checkout,registration,account}_visibility
• lifterlms_voucher_field_registration_visibility

These were superseded by LifterLMS Forms in 5.0.0. On any install since then they no longer describe how a form is actually rendered, so the values reported are at best stale and at worst misleading when someone is reading a system report to debug a form.

This removes those reads. $data['open_registration'] sat inside the same block but reads lifterlms_enable_myaccount_registration, which is still a live setting, so it is kept and moved above the removed lines.

What is deliberately left alone

The other readers of these options are still doing real work:

File	Why it stays
includes/forms/class-llms-form-templates.php	Reads them to build form templates when migrating a pre-5.0.0 install. This is the "functional" usage noted in the issue.
includes/admin/tools/class-llms-admin-tool-wipe-legacy-account-options.php	Exists specifically to delete these options.
includes/functions/updates/llms-functions-updates-300.php	Historical 3.0.0 migration.

The class.llms.notification.view.student.welcome.php line referenced in the issue already went through LLMS_Forms::instance()->are_usernames_enabled(), which reads llms_forms_username_locations — so that one appears to have been resolved since the issue was filed.

One thing worth a maintainer's eye

get_llms_settings() feeds both the admin System Report and LLMS_Tracker. So this changes the shape of the tracker payload — fourteen keys disappear. That seems like the intent of the issue, but if anything downstream consumes those keys I'd rather you tell me now than find out after a release. Happy to restrict the change to the system report and leave the tracker untouched if you prefer.

Fixes #1675

How has this been tested?

• Grepped for every reader of lifterlms_user_info_field_* and lifterlms_voucher_field_* to confirm the three remaining call sites above are the only ones, and that each is still load-bearing.
• Confirmed nothing consumes the removed $data keys (checkout_names, registration_address, and so on). LLMS_Admin_System_Report::output() iterates the array generically rather than referencing keys by name, so the only visible effect is that those rows stop being rendered.
• Confirmed no test asserts on the removed keys. The test hits for these option names are in the wipe-tool and form-template suites, which exercise the options themselves rather than the report.
• Ran composer run-script check-cs-errors against this file on both upstream/dev and this branch. Both report the same 16 pre-existing errors (PSR2.Methods.FunctionClosingBrace.SpacingBeforeClose ×15, PSR2.Classes.ClassDeclaration.CloseBraceAfterBody ×1) and nothing else — this change adds no new PHPCS violations.

I did not run PHPUnit locally (it needs a MySQL instance and the WP test suite); the workflow runs on this PR.

Types of changes

Removal of superseded reporting data — no change to how forms behave.

Checklist:

• This PR requires and contains at least one changelog file.
• My code has been tested.
• My code passes all existing automated tests.
• My code follows the LifterLMS Coding & Documentation Standards.