Fix to intermittent failure of jit test 200w1d-09_cpp_r.exe

Fix to intermittent failure of jit test 200w1d-09_cpp_r.exe

This is a long standing bug in xarch emitter that repros when a static field
access results in the following IR

lclvar =  GT_IND(GT_LEA(GT_CLS_VAR_ADDR, offset=200))

GT_CLAS_VAR_ADDR represents address of the static class object and
offset is used to access a field of a static class.

In this case codegen of GT_IND would call emitInsMov(treeNode= GT_IND)
emiInsMov is checking whether 'base' of addr is GT_CLS_VAR_ADDR and if
so is disregarding offset/indiex/scale fields within addr mode.  As a
result code generated is

lea      rdx, [reloc classVar[0xddc44ce8]]
movsd    xmm10, qword ptr [reloc classVar[0xddc44ce8]]

The bug is that emitInsMov() should be checking that oper of addr of GT_IND
is GT_CLS_VAR_ADDR. Same issue exists in GT_STOREIND case.  After the
fix the following code is generated

lea      rdx, [reloc classVar[0xdc5a4ce8]]
movsd    xmm10, qword ptr [rdx+200]

Why this bug repros intermittently?  fgMorphField() when morphing a static
field access obtains static's addr and checks to see whether its addr
can be encoded as pc-relative 32-bit offset.  If so then fgMorphField() will create
GT_CLS_VAR_ADDR to represent static's addr.  If static's addr cannot be
encoded pc-relative 32-bit offset then it will create long type icon to represent the
address.  Later long icon + offset is folded into a single long constant
and the test passes in this case.  The test fails whenver GT_CLS_VAR_ADDR +
offset materializes in IR which in turn depends on the distance between
jitted code address and the static's address. In most cases statics
were at a distance that cannot be encoded as pc-relative and hence works
correctly.  Hence the intermittent failure of this test.

Commit migrated from https://github.com/dotnet/coreclr/commit/3eb08188497063e8251144ba1f78d23e1b9306f8