consider removing verifythrow(..) strings

These are un-localized strings that appear in the InternalErrorException message if we hit a bug in ourselves. Roughly across all the assemblies, they come to about 50-60KB even deduplicated:

https://gist.github.com/danmoseley/d29a91c87fa8617de4f2963c5160b236

The message is rarely if ever useful to anyone that isn't a developer in this repo.

Suggestion: replace these messages with a unique integer. Then instead of say
```
This is an unhandled exception in MSBuild -- PLEASE UPVOTE AN EXISTING ISSUE OR FILE A NEW ONE AT https://aka.ms/msbuild/unhandled.
MSB0001: Internal MSBuild Error: Assuming 1-to-1 mapping between configs and results. Otherwise it means the caches are either not minimal or incomplete
```
which means nothing to customers, they would get eg
```
This is an unhandled exception in MSBuild -- PLEASE UPVOTE AN EXISTING ISSUE OR FILE A NEW ONE AT https://aka.ms/msbuild/unhandled.
MSB0001: Internal MSBuild error with code MSB0001-1234
```
... which is equally stable and if anything is MORE searchable.

Assuming the deprecated engine bits aren't touched, this would save about 30-40KB on disk. Equally valuable, it would make it clearer which strings are resource strings. Right now half of the VerifyThrow's are passed resource names and half are passed these unlocalized messages and we've repeatedly mixed them up. If we remove the latter, things become clearer: everything is a resource string.

Start by reviewing the VerifyThrow(..) usages across the MSBuild assemblies and compare them with the examples in the linked gist. Check how InternalErrorException messages are assembled and avoid touching deprecated engine bits unless needed. Done means unlocalized diagnostic strings are replaced by stable unique codes, resource-string usages are unambiguous, and the reported size reduction is verified.

Written by the indexing model from the issue text.