Fix: prefer-numeric-literals doesn't check types of literal arguments

[mdjermanovic]

What is the purpose of this pull request? (put an "X" next to item)

[X] Bug fix

This PR can produce only fewer warnings in prefer-numeric-literals.

From the documentation:

This rule disallows calls to parseInt() or Number.parseInt() if called with two arguments: a string; and a radix option of 2 (binary), 8 (octal), or 16 (hexadecimal).

This PR fixes the following:

1. The rule didn't check the type of the first literal argument.

It did check if it's a Literal. Now it also checks if it's a string literal.

This probably didn't cause some notable problems, but it isn't by the spec (which is explicit about the first argument), and it might be unwanted in some cases.

/* eslint prefer-numeric-literals: error */

parseInt(1e8, 2); // fixed to 0b100000000;

Demo Link

2. The rule didn't check the type of the second literal argument.

The only check was whether the literal's value, when coerced to string, exists as a key in the object map, so it ended up targeting the following radix arguments:

2, 8, 16, "2", "8", "16", 2n, 8n, 16n

It's changed now to target only number arguments 2, 8, and 16.

Targeting string radix arguments is inconsistent with the radix rule, which reports these as invalid (Demo Link).

Bigint radix argument causes ESLint to crash when the rule tries to evaluate the expression:

/* eslint prefer-numeric-literals: error */

parseInt('11', 2n); // TypeError: Cannot convert a BigInt value to a number.

Demo Link

3. The rule used objects as maps.

Demo Link

What changes did you make? (Give an overview)

The rule now targets only parseInt and Number.parseInt that have a string literal as the first argument and a number literal as the second argument.

Also, converted objects used as maps to Map.

Is there anything you'd like reviewers to focus on?