Set numString properly for numeric tokens generated by ##.

Previously, it was not necessarily set correctly for the newly-generated token. This would result in incorrect behavior if that token was an operand to another ## operator, as in the following example:

#define x(a,b,c) a##b##c
x(1,2,3)

Scanner.pas

@@ -1311,6 +1311,7 @@ var
    class1,class2: tokenClass;           {token classes}
    i: integer;                          {loop variable}
    kind1,kind2: tokenEnum;              {token kinds}
+   lsaveNumber: boolean;                {local copy of saveNumber}
    lt: tokenType;                       {local copy of token}
    str1,str2: stringPtr;                {identifier strings}
 
@@ -1379,7 +1380,10 @@ else if class1 in numericConstants then begin
       end; {else}
    workString := concat(tk1.numString^, str2^);
    lt := token;
+   lsaveNumber := saveNumber;
+   saveNumber := true;
    DoNumber(true);
+   saveNumber := lsaveNumber;
    tk1 := token;
    token := lt;
    goto 1;

cc.notes

@@ -1612,6 +1612,8 @@ If you use #pragma debug 0x0010 to enable stack check debug code, the compiler w
 
 11. If fclose() was called on a file created by tmpfile() at a time when there was very little free memory available, it could corrupt memory and cause a crash.  (This will no longer happen, but the file still may not be deleted if there is insufficient memory available when fclose() is called.)
 
+12. If a numeric token formed using a ## preprocessor operator was an operand for another ## preprocessor operator, the resulting token would be incorrect.
+
 -- Bugs from C 2.1.1 B3 that have been fixed in C 2.2.0 ---------------------
 
 1.  There were various bugs that could cause incorrect code to be generated in certain cases.  Some of these were specific to certain optimization passes, alone or in combination.