This PR is done and can be merged whenever you're comfortable doing so. 😄

This change breaks string concatenation logic for CompileTimeConstantExpr and might also negatively affect custom user queries. Consider for example 'a' + 'b'; with this change getStringValue() erroneously has "ab" as result, while the correct result is an int representing ((int) 'a') + ((int) 'b') (unfortunately this does not seem to be covered by any tests).
Currently the logic in CompileTimeConstantExpr is also incomplete, but once it gets closer to the JLS, this would affect more cases, such as 'a' + 1.
Similarly a user who is using getStringValue() in their query will likely expect that the expression is really of type String, and not of type char / Character, which is incompatible with String.

It looks like the reason why this change to getStringValue() was proposed, was to simplify a very specific case where a CodeQL expression represents a read of a field of type char or String, see https://github.com/github/codeql/pull/8032/files#r818222618.
Would it therefore make sense to revert the changes done to getStringValue(), and instead modify the code for that specific use case? To me that looks like a saner solution.

Hm, sure, the concat case clearly needs fixing. Concat of string + char is nice to have though for example. @JLLeitschuh how about amending to have a separate getStringifiedValue, and use that to handle concatenation in the particular case where the resulting expression is of type String? Thus 'a' wouldn't have a getStringValue (but would have a getStringifiedValue), but "a" + 'b' would have both.

getStringifiedValue is hard to implement in general of course since e.g. floating point numbers are likely to stringify differently to how the user wrote them in source (e.g. final double d = 1.0e1 will stringify as 10.0), but it would be acceptable in my view to give a partial implementation so long as that is clearly noted in getStringifiedValue's qldoc.

getStringifiedValue is hard to implement in general of course since e.g. floating point numbers are likely to stringify differently to how the user wrote them in source (e.g. final double d = 1.0e1 will stringify as 10.0), but it would be acceptable in my view to give a partial implementation so long as that is clearly noted in getStringifiedValue's qldoc

To me that looks acceptable as well (if the qldoc describes that the value is converted to string), because in Java for example "a" + 1.0e1 is "a10.0", so this would not be that different from what one might expect.

Thanks for the feedback! Resolved here: #8360