ctags: fix improper use of "const" type qualifier

The external declaration of "File" in read.h (defined in read.c) was
improperly tagged as "const" for it not to be modifiable outside of
read.c.  Although it is good to protect this global variable against
improper modification, the use of "const" here makes it perfectly valid
for the compiler to assume that the fields in this structure never
changes during runtime, thus allowing it to do optimizations on this
assumption.  However, this assumption is wrong because this structure
actually gets modified by many read.c's functions, and thus possibly
lead to improper and unexpected behavior if the compiler sees a window
for optimizing fields access.

Moreover, protecting "File" as it was with the "const" type qualifier
required a hack to be able to include read.h in read.c since "const"
and non-"const" declarations conflicts.

Actually, at least the JavaScript parser did suffer of the issue,
because it calls getSourceLineNumber() macro (expanding to a direct
"File" member access) several times in one single function, making it
easy for the compilers to cache the value as an optimization.  Both GCC
and CLang showed this behavior with optimization enabled.  As a result,
the line numbers of JavaScript tags were often incorrect.

tagmanager/ctags/read.h

@@ -10,12 +10,6 @@
 #ifndef _READ_H
 #define _READ_H
 
-#if defined(FILE_WRITE) || defined(VAXC)
-# define CONST_FILE
-#else
-# define CONST_FILE const
-#endif
-
 /*
 *   INCLUDE FILES
 */
@@ -96,7 +90,8 @@ typedef struct sInputFile {
 /*
 *   GLOBAL VARIABLES
 */
-extern CONST_FILE inputFile File;
+/* should not be modified externally */
+extern inputFile File;
 
 /*
 *   FUNCTION PROTOTYPES