Restrict allocation of executable memory by DebuggerHeap

[Djuffin]

DebuggerHeap is a common class that is used for both executable and
non-executable memory allocations by debugging infrustructure.
On Windows, OS supports concept of executable heap and CLR doesn't need
to do anything extra for each executable allocation. On Linux/OSX
this is not true. That's why this changes preserves fExecutable flag for each heap
and makes sure that we mark memory as executable only when it is necessary.

This change should address performance degradation described in #711.
It doesn't fix managed debugging on CentoOS, but allows to run CoreCLR processes there without constant SELinux warnings.

[Djuffin]

This PR makes sure changes from #1963 get to RC1
/cc @tzwlai @mikem8361 @pgavlin

[mikem8361]

LGTM

[pgavlin]

LGTM as well.

[ellismg]

@dotnet-bot test Ubuntu x64 Debug Build

[ellismg]

I merged this before the JIT tests completed. It seemed like they have been taking a long time.

[ellismg]

(They did pass on Windows Retail)

[ellismg]

Looks like there was a test failure @Djuffin, is this a real issue specific to the RC1 branch? Will we need to take another fix or roll this back?

[Djuffin]

@ellismg I'd be surprised to learn that my change made one JIT test on Windows timeout.
Especially given that actual behavior change was made only in code under FEATURE_PAL.

d:\j\workspace\dotnet_coreclr\debug_windows_nt_prtest\bin\tests\Windows_NT.x64.debug\JIT\CodeGenBringUpTests\LocallocLarge.cmd Timed Out Raw Output

[AndyAyersMS]

@ellismg @Djuffin there is definitely something odd going on with the check build testing recently... see #1966.

I can't repro any slowdowns on the LocallocLarge test locally so suspect something about the CI configuration is off. Matt says he enabled some parallelism on windows so that could be it.