After updating the custom spend limit on the approve screen, the data
for the transaction was not being updated. Instead it showed the
original transaction data. The transaction data was being updated
correctly in the final transaction though.

The approve screen has been updated to ensure changes to the custom
spend limit are reflected correctly in the data shown.

In the case where the initial spend limit for the `approve` function
was set to the maximum amount, editing this value would result in the
new limit being silently ignored. The transaction would be submitted
with the original max spend limit.

This occurred because function to generate the new custom data would
look for the expected spend limit in the existing data, then bail if
it was not found (and in these cases, it was never found).

The reason the value was not found is that it was erroneously being
converted to a `Number`. A JavaScript `Number` is not precise enough to
represent larger spend limits, so it would give the wrong hex value
(after rounding had taken place in the conversion to a floating-point
number).

The data string is now updated without relying upon the original token
value; the new value is inserted after the `spender` argument instead,
as the remainder of the `data` string is guaranteed to be the original
limit. Additionally, the conversion to a `Number` is now omitted so
that the custom spend limit is encoded correctly.

Fixes #7915

The custom spend limit was previously not validated. It did have a
minimum of zero set, but this didn't have any affect (that minimum is
used for form constraint validation, and this field wasn't in a form).
The field was never checked to ensure the contents didn't exceed the
maximum.

The field is now checked for values that exceed the maximum, and
invalid values in general (including negative values).

The parameters to the `showEditApprovalPermissionModal` were also
alphabetized to make them easier to read. In the course of doing this,
I noticed that the origin was missing from one of the calls. This was
responsible for the modal saying "Spend limit requested by undefined"
when clicking "Edit" under the transaction details. This has been
fixed.

The ENS resolver will now bail on any network other than mainnet.

* Update yarn.lock cross-spawn versions
* Use ethereum-ens-network-map@1.0.2

* Add warning when editing a known token with watchAsset API

* Add warning when watchAsset attempts to reuse token symbol

* Revert "Revert "Update Wyre ETH purchase url" (#7631)"

This reverts commit bc67d1eecabb123bf21445e604780d2454d52d3e.

* Restrict widget to just debit card payments

Apple Pay apparently only works on Safari.

Update packages to address the following security advisories:
* https://www.npmjs.com/advisories/1474
* https://www.npmjs.com/advisories/1475
* https://www.npmjs.com/advisories/1476
* https://www.npmjs.com/advisories/1480
* https://www.npmjs.com/advisories/1482

ENS currently supports a variety of tlds in addition to `.eth`, and
more will be supported in the future. Rather than hard-code a list of
supported ENS tlds, all valid domain names will now be interpreted as
potential ENS addresses in our address input component.

Closes #7978