Preserve webp setting options with update from versions older than 2.2

[wordpressfan]

Description

Fixes #848
Fixes #850

Documentation

User documentation

Here we added back the webp option names, so those old options (display_webp, display_webp_method, and convert_to_webp) will be kept on the database but without UI.

Then when the user updates to the latest version we will move those options' values to the corresponding new ones.

Technical documentation

Explain how this code works. Diagram & drawings are welcomed.

Type of change

Delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue).

New dependencies

List any new dependencies that are required for this change.

Risks

List possible performance & security issues or risks, and explain how they have been mitigated.

We only have one risk that I can think of now, having not used settings in the database but it worth having them because also what if any user reverted back to an older version of imagify after updating to the latest version, with this change, he will find everything set properly in older versions too.

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[Mai-Saad]

related tests https://docs.google.com/spreadsheets/d/1Johcl8EGXoUVF073rs8ljMQgDU0wQr3A9irPTWRqp4Q/edit?usp=sharing