Ensure DOTNET_MaxVectorTBitwidth is interpreted as a decimal based input, not hexadecimal

[tannergooding]

As per the title, this simply ensures that DOTNET_MaxVectorTBitWidth=256 is interpreted as 256 and not as 598. This will better match user expectations for the value, matches the value users pass into NAOT for the equivalent configuration knob, etc.

An equivalent to ReinterpretHexAsDecimal already exists for the JIT config values and is being used by various options, including PreferredVectorBitWidth.

I missed that CLRConfig::LookupOptions::ParseIntegerAsBase10 exists and have updated to use that instead.

[tannergooding]

CC. @dotnet/jit-contrib, @jkotas

A simple one line change to the DOTNET_MaxVectorTBitWidth config value so its interpreted as decimal and consistent with how the same parameter is interpreted for NAOT, etc

[EgorBo]

I really dislike our "hex by default" behavior but I guess there is nothing we can do about it now