Summary of Changes

To help consolidate some duplicate code and make maintenance a little easier, I propose to deprecate the JInput class chain in favor of the Framework's Input package and that the latter code be the only code used as of 4.0. Note this will require merging some patches committed here to the Framework repo but the way this PR is structured we do NOT need to do that prior to this being merged.

To help move this forward, the base JInput class now extends the Joomla\Input\Input class and uses its methods and class member vars as practical. This will allow code to typehint the namespaced class once accepted. Later pull requests can adjust the CMS' typehints for this.

If accepted, this also gives access to a new API method added in the Framework package: JInput::exists()

Testing Instructions

In all cases, the existing Platform classes (JInput*) should still be used for all interactions with the JInput API right now and filtering should continue to be done with a JFilterInput object; no changes are made that would cause it to begin using Joomla\Input\* class objects at this time. This is important because the files object specifically has additional checks that are not yet part of the Framework code (input and filter packages).

All interactions with the JInput API should continue to work exactly as they do without this patch. Data should be correctly read from the requested data source, manipulated correctly, and in the case of file uploads continue to go through the JFilterInput::isSafeFile() check when not requesting raw data.

Documentation Changes Required

At 4.0, the class name references in https://docs.joomla.org/Retrieving_request_data_using_JInput should be updated. In terms of API usage, no changes are needed; the object will continue to be accessible by JFactory::getApplication()->input.