Drop the duplicated InputPage machinery once the shared base is extensible

[khatchad]

OptimizeStreamRefactoringWizard's input page reimplements the shared InputPage base's machinery self-contained: its own createControl, addIntegerButton, addBooleanButton, and loadSettings. It does this because the base currently offers no hook to add option controls and keeps settings/processor private.

Once ponder-lab/Common-Eclipse-Refactoring-Framework#50 adds the addOptions hook and seed-safe addIntegerButton/addBooleanButton, this wizard can drop the duplicated members and override addOptions instead, reusing the base's settings persistence.

Blocked by ponder-lab/Common-Eclipse-Refactoring-Framework#50.

[khatchad]

Unblocked. ponder-lab/Common-Eclipse-Refactoring-Framework#50 is merged into master (ponder-lab/Common-Eclipse-Refactoring-Framework#51) and will ship in the upcoming Common 5.3.0 release.

The shared InputPage base now provides exactly what this issue was waiting on:

• A protected void addOptions(Composite optionComposite) hook (default no-op), called by createControl after loadSettings() and after the option composite is created.
• Seed-safe overloads addIntegerButton(text, key, int defaultValue, consumer, parent) and addBooleanButton(text, key, boolean defaultValue, consumer, parent) that seed the key into the dialog-settings section when absent, so they work on a fresh section.

So OptimizeStreamRefactoringWizard's input page can drop its duplicated createControl/addIntegerButton/addBooleanButton/loadSettings and instead override addOptions, passing the processor's current value as the default, reusing the base's settings persistence. No settings/processor accessors are needed since the default is supplied by the caller.

Once Common 5.3.0 is released, bump the target-platform dependency to 5.3.0 and do the cleanup.