Initial commit of native shims building in corefx

[nguerrera]

cc @stephentoub

This PR replaces #2303 and dotnet/coreclr#1225.

It makes progress towards #2137 and #2301

Changes:

• Add src/Native/ with build scripts based on dotnet/coreclr
• Add src/Native/System.IO.Native with a sample shim library having just stat shims
• Make System.Console use System.IO.Native instead of libcoreclr for its direct usage of stat
• Hack to build and deploy native shims in run-test.sh (pending real CI support / cc @mmitche)
• Add some guidelines on writing shims to interop-guidelines.md

Notes:

• I've reverted back to the naming conventions established by System.Security.Cryptography.Native.so. I'd still like to think some more about the right names, but I'll leave that to the packaging decisions (#2302) and make a pass over to rename if/when we decide to change.
• I have only tested on Linux so far
• There is still code feedback on the prior PRs that needs addressing, but I wanted to get what I have in terms of building everything in corefx up first

[stephentoub]

I think it'd be worth noting explicitly that this isn't just about Linux vs OS X vs FreeBSD vs... etc. It's also about 32-bit vs 64-bit, processor architecture, etc.

[stephentoub]

Thanks, Nick. Great to see this starting to come online.

[mmitche]

This is fine for now. As soon as this gets checked in I'll add the necessary legs. Do you need new parameters in run-test to indicating the location of the corefx Linux native binaries, or will that fall under the corefx Linux managed binaries?

[nguerrera]

OK. Can I leave the path handling to you once we have the proper legs? We need to (1) build src/Native on the target OS and (2) get everything in bin/OS.arch.config/Native in to the overlay. I'm not sure if that can be inferred from the existing args or not.

[weshaggard]

I'm not opposed to having a "src\Native.Native" file layout but I wanted to at least ask the question of whether or not we felt these native libs should live next to the managed versions that will use them or if we feel they are general purpose enough to be isolated like you are proposing? Do we know what package they will end up in when we start packaging these? If for example we expect System.IO.Native.dll to be in the System.IO package then we may want to keep it along side System.IO but if it is going to be somewhere else then we can keep it isolated.

At a high level I intend for anything that ships in a package together to live together so they can mostly be independent and we can move or build them independently. For example anything we plan to ship in the System.IO package, including any contracts or facades I would hope to live under src\System.IO directory.

[nguerrera]

@weshaggard I believe these should be packaged on their own and shared between managed packages. See my previous comments on dotnet/coreclr#1225. With that said, I'm deferring the packaging part for now to #2302 and we may want to reorganize based on what we decide there.

[stephentoub]

LGTM. Thanks, Nick.

[stephentoub]

@dotnet-bot test this please