Enforce stricter integer parsing on encode function

[ebramanti]

Currently, the encode function in hashids is using parseInt in order to validate that a stringified number is indeed a number before encoding. However, there is a caveat to parseInt, detailed in MDN's documentation:

If parseInt encounters a character that is not a numeral in the specified radix, it ignores it and all succeeding characters and returns the integer value parsed up to that point.

If an API consumer were to pass hashids.encode('B6'), this would result in a proper result of '' since the API specifies returning an empty string if an integer is not received.

However, if the consumer were to pass hashids.encode('6B'), the parseInt function would parse this as 6 and ignore the succeeding characters. This would allow the encode function to continue with the encode, even though the function was passed a bad value.

I've updated the tests to demonstrate the issue. To address the bug, I added a stricter filterInt function. This function verifies that the number being passed is indeed an integer before executing parseInt. I pulled filterInt from MDN's documentation on parseInt and modified it to be a bit cleaner.

Thanks to @juliancoleman for pairing with me to find/implement a fix for this bug.

[coveralls]

Coverage remained the same at 100.0% when pulling 0036859 on jadengore:feature/encode-validation-integer-parsing into b8b0a6e on ivanakimov:master.

[jd327]

Awesome description & good catch. Thank you @jadengore.