Use AdvancedGasInputs in AdvancedTabContent

[Gudahtt]

The AdvancedGasInputs component was originally extracted from the AdvancedTabContent component, duplicating much of the rendering logic. They have since evolved separately, with bugs being fixed in one place but not the other.

The inputs and outputs expected weren't exactly the same, as the AdvancedGasInputs component converts the input custom gas price and limit, and it converts them both in the setter methods as well. The GasModalPageContainer had to be adjusted to avoid converting these values multiple times.

A few other changes were made to avoid using variables as parameters to the localization helper function. This is to make it easier to detect when messages are unused.

Closes #6872

[Gudahtt]

This should be ready to review now. The tests had been failing because a debounce was added to one of the fields that wasn't there before, so an additional pause was required.

The previous gas controls in AdvancedTabContent are fairly similar to AdvancedGasInputs (the latter was derived from the former after all), but there were some style differences. I tried to make it look fairly similar.

Here is the old version:

And here is the new version:

[Gudahtt]

I had to update this PR to fix tests after a rebase, then I reconsidered an earlier decision I made.

Both components dealt with input debouncing separately, both in less than ideal ways. AdvancedTabContent didn't debounce either field, but it did debounce the check for whether the gas limit field was below the minimum value. So if a less-than-minimum value was set, it would be propogated upwards and could be saved if the user clicked 'Save' quickly enough. After a second delay it would snap back to the minimum value. The AdvancedGasInputs component debounced both fields, but it would replace any gas limit below the minimum with the minimum value. This led to a problem where a brief pause during typing would reset the field to 21000.

At first, the AdvancedGasInputs approach was chosen for the new merged component. I figured that this was the "less bad" of the two, and the problem encountered was an existing issue that hadn't been flagged yet as a problem. Though after reconsidering, I decided to mitigate it now, as introducing this problem in new contexts would basically constitute a regression.

The new behavior now matches the old AdvancedGasInputs behavior, except that it was updated to no longer change the gas limit if it was below the minimum. Instead it displays an error. Parent components were checked to ensure they would detect the error case of the gas limit being set too low, and prevent the form submission in those cases. Of the three parents, one had already dealt with it correctly, one needed to convert the gas limit from hex first, and another needed the gas limit check added.

[danjm]

QA'd and reviewed, looks good.