Don't accidentally accept invalid glyphNames which *appear* to follow the Cdd{d}/cdd{d} format in PartialEvaluator._buildSimpleFontToUnicode (issue 11697)

The /Differences array of the problematic font contains a `/c.1` entry, which is consequently detected as a *possible* Cdd{d}/cdd{d} glyphName by the existing heuristics.
Because of how the base 10 conversion is implemented, which is necessary for the base 16 special case, the parsed charCode becomes `0.1` thus causing `String.fromCodePoint` to throw since that obviously isn't a valid code point.

To fix the referenced issue, and to hopefully prevent similar ones in the future, the patch adds *additional* validation of the charCode found by the heuristics.

src/core/evaluator.js

@@ -2574,7 +2574,7 @@ var PartialEvaluator = (function PartialEvaluatorClosure() {
                 code = unicode;
               }
           }
-          if (code) {
+          if (code > 0 && Number.isInteger(code)) {
             // If `baseEncodingName` is one the predefined encodings, and `code`
             // equals `charcode`, using the glyph defined in the baseEncoding
             // seems to yield a better `toUnicode` mapping (fixes issue 5070).

test/pdfs/.gitignore

@@ -288,6 +288,7 @@
 !issue2537r.pdf
 !bug946506.pdf
 !issue3885.pdf
+!issue11697_reduced.pdf
 !bug859204.pdf
 !annotation-tx.pdf
 !annotation-tx2.pdf

test/test_manifest.json

@@ -3369,6 +3369,13 @@
        "type": "eq",
        "about": "The same PDF file as in bug1175943."
     },
+    {  "id": "issue11697",
+       "file": "pdfs/issue11697_reduced.pdf",
+       "md5": "5b3793a76f92b357bd8ccc02e1c54ba0",
+       "rounds": 1,
+       "link": false,
+       "type": "eq"
+    },
     {  "id": "issue1878",
       "file": "pdfs/issue1878.pdf",
       "md5": "b4fb0ce7c19368e7104dce3d0d34bcb3",
@@ -4428,5 +4435,5 @@
       "md5": "f84ce8b7414f6a18e75a6ce69c902501",
       "rounds": 1,
       "type": "eq"
-   }
+    }
 ]