[10.x] Migrate JSON data to shared InputBag

[timacdonald]

fixes #47877

We recently made a change to how the JSON input was handled due to a change in Symfony.

With the change, we created a new InputBag instance for the request data and left the json data in the original ParameterBag.

This meant that when data was merged into the request, via request()->merge(), it was not shared with the request InputBag.

This PR migrates the json input to an InputBag as well and then uses that InputBag instance as the request data when creating a new Request instance.

Request merge now works as it previously did, but with the caveat that all data within the json payload must be a scalar type. Object in JSON are decoded as associative arrays.

This does bring consistency across all input types, so I feel this is probably the best approach anyway.

[ImJustToNy]

any plans to backport this to 9.x? #47919

[jnoordsij]

For reference/people who might end up with similar errors to mine: this change caused some Symfony\Component\HttpFoundation\Exception\BadRequestException exceptions with message Input value "<field>" contains a non-scalar value. to appear in my application, running roughly the following code:

public function foo(\Illuminate\Foundation\Http\FormRequest $request)
{
    $data = $request->json();
    $some_array = $data->get('field'); // where field is some array in the POST body of the handled request
    ...
}

This is due to the json method now returning an InputBag instance instead of a ParameterBag, which does not allow retrieving non-scalar values (e.g. arrays) through the get method.

The fix for this is to use the Laravel documented way of retrieving input instead of using the underlying Symfony class:

public function foo(\Illuminate\Foundation\Http\FormRequest $request)
{
    $some_array = $request->input('field'); // where field is some array in the POST body of the handled request
    ...
}