Incorrect type for `logger.level`

Before filing issues, please check the following points first:

• Please don't open issues for security issues. Instead, file a report at https://www.npmjs.com/advisories/report?package=handlebars
• Have a look at https://github.com/handlebars-lang/handlebars.js/blob/master/CONTRIBUTING.md
• Read the FAQ at https://github.com/handlebars-lang/handlebars.js/blob/master/FAQ.md
• Use the jsfiddle-template at https://jsfiddle.net/4nbwjaqz/4/ to reproduce problems or bugs: forked to https://jsfiddle.net/8mg3sqn6/

This will probably help you to get a solution faster.
For bugs, it would be great to have a PR with a failing test-case.

For usability, the types for logger are not good. logger.level is specifically typed as number, and only number, not number | string. But then logger.level is initialized as a string. This is confusing.

Worse, logger.ERROR, logger.WARN, logger.INFO, and logger.DEBUG are typed, but they do not map to any value. They look like constants to be used in your own code, but they are undefined.

This means there are two ways to set Handlebars' log level, both unappealing:

• Ignore the clear typing of logger.level and set it to a string anyway, which will throw TypeScript errors but work. Override this by miscasting, i.e., as unknown as number.
• Dig into Handlebars' code directly and manually map level names to the indexes of the level names in logger.methodMap. These are the values we might expect logger.ERROR, logger.WARN, etc. to represent, but they don't.

To my mind, logger.level should definitely be typed as number | string at the very least, or better yet, number | 'error' | 'warn' | 'info' | 'debug'. And the constants should be hardcoded or at least set when Handlebars starts.

Start by inspecting Handlebars' logger and its methodMap, focusing on how logger.level is initialized and typed and how logger.ERROR, logger.WARN, logger.INFO, and logger.DEBUG are defined. Done means the accepted level values match runtime behavior and the constants expose usable values without requiring TypeScript casts or manual methodMap mapping.