[SimplifyLibCalls] Pre-commit test case showing bug with wide char support

The ValueTracking support for getting the string length of a wchar_t
string (e.g. using wcslen) seem to be having some bugs.

Problem I've seen is that llvm::getConstantDataArrayInfo is taking
both a "ElementSize" argument (basically indicating size of a
char/element in bits) and an "Offset" which afaict is an offset
in the unit "number of elements". Then it also use
stripAndAccumulateConstantOffsets to get a "StartIdx" which afaict
is calculated in bytes. The returned Slice.Length is based on
arithmetics that add/subtract variables that are having different
units (bytes vs elements). Most notably I think the "StartIdx" must
be scaled using the "ElementSize" to get correct results.

This patch just adds a new test case showing that we get a wrong
result when doing wcslen(x + c). The actual fix to the above problem
will be done in a follow up commit.

Differential Revision: https://reviews.llvm.org/D135262