Fix #578: lexer wrongly interprets ".e[0-9]" as a number with scientific notation.

[niconoe-]

@williamdes Here is my fix about #578.

On the first and fourth (because I forgot to move from state 10 to state 4) commits, you can see that token ".e4" is parsed as is and wrongly considered as a number, causing the effect of not being able to detect the "." in "database_name.table_name" as an operator, and cascading to a failure in the parser.

On the second commit, with the fix, you can see ".e4" is no longer a token, but instead "." is a token, and "e4" is another one, which is not a number.

On the third commit… eh, please don't look, I just forgot to remove a debuging stuff 😓

[niconoe-]

Could you please add a test with the example from the issue?

Yup, that's done :slightly_smiling_face:

You can see on parseLoad8.out that the tokens are correctly set up, and the statement is having the expected properties without any error.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.83%. Comparing base (afe9173) to head (a004a6c). Report is 55 commits behind head on 5.10.x.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## 5.10.x #579 +/- ## ============================================ + Coverage 96.81% 96.83% +0.01% + Complexity 2294 2259 -35 ============================================ Files 70 71 +1 Lines 5248 5152 -96 ============================================ - Hits 5081 4989 -92 + Misses 167 163 -4 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.