- Produce a merged mibc with all scenarios squished together
- Properly attach the mibc data to the incremental build for System.Private.CoreLib
  - This can't be done for the framework here. It will require mibc integration in the SDK
- Enable pgo optimization in checked builds
- Enable pgo optimization in framework compile for outerloop runs

* Use nuget standardized properties

Requires https://github.com/dotnet/arcade/pull/7212. Helps with the pkgproj to csproj conversion.

* Use CSProj for packing Platforms package

* Port GenerateRuntimeGraph task

This ports the GenerateRuntimeGraph task from arcade as of
https://github.com/dotnet/arcade/tree/d005a8ce6bb81129f9c3a4a907e1b7ccbf2504d5

* Refactor GenerateRuntimeGraph into separate files

* Add test for GenerateRuntimeGraph

* Fix up path to runtime.json

* Don't filter inner builds when building Platforms task

* Skip tests RuntimeGraph task tests on some platforms

* Exclude browser from testing instead of wasm

* Another try at suppressing testing on Browser

Previously, we have had four iOS RIDs:

iOS-arm
iOS-arm64
iOS-x86
iOS-x64

Apple has never shipped an iOS device with an x86 or x64 processor. Instead, the x86/x64 RIDs have meant "iOS simulator with these arches" as opposed to "iOS with these arches". Amongst other things, that means building against a DIFFERENT SDK, iPhoneSimulator.platform vs iPhoneOS.platform

In the Apple Silicon future, the iOS simulator is now an ARM64 binary - so we need:

iOS-arm
iOS-arm64
iOS-arm64, but built against the simulator SDK not the device SDK
iOS-x86
iOS-x64
Clearly, there's a problem.

The solution is to move the simulators to a different RID, to avoid the overloading issue:

iOS-arm
iOS-arm64
iOSSimulator-arm64
iOSSimulator-x86
iOSSimulator-x64

This PR introduces the new entries in the RID graph, moves our existing iOS-x{86,64} to iOS-sim-x{86,64}, adds a new iOS-arm64.

The above also applies for tvOS, with a smaller set of OSes:

tvOS-arm64
tvOSSimulator-arm64
tvOSSimulator-x64

Ref: #48216

- Implementation is parallel to existing ibc handling, so that it can be toggled on/off by adjusting the `UsingToolIbcOptimization` property
- Use the same data for all assemblies produced in current build
- Apply data to release builds only
- Disable mismatch assertions in jit for current state where il mismatches are common

* Add msbuild task to generate binary runtimeconfig format

* Update property name due to naming conversion.

* Fixed more formatting issue

* Fixed one more naming convention

* Update src/tasks/RuntimeConfigParser/RuntimeConfigParser.cs
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Update src/tasks/RuntimeConfigParser/RuntimeConfigParser.cs
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Update src/tasks/RuntimeConfigParser/RuntimeConfigParser.cs
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>

* Fixed comments

* Update src/tasks/RuntimeConfigParser/RuntimeConfigParser.cs
Co-authored-by: NDan Moseley <danmose@microsoft.com>

* Fix error handling
Co-authored-by: NRyan Lucia <ryan@luciaonline.net>
Co-authored-by: NDan Moseley <danmose@microsoft.com>

The SDK already enables deterministic builds by default. No need to set this property again.

Armel was not treated like arm or arm64, causing the wrong folders to be used during crossgen

Fix crossgen2 RID specific package names and use more specific property
names to avoid confusion about shared framework meanings.

* Remove duplicated ILLink PackageReference

The Arcade.SDK already package refrences the ILLink package. The
duplicate reference in illink.targets caused SDK errors as the Arcade
reference has IsImplicitlyDefined set which doesn't allow an additional
reference with the same identity.

Also, as the ILLink package already exposes the path to the assembly via
its props file, using that instead of manually constructing the path to
the assembly.

The SDK target version update is required as the sequencing of the
ILLink.props file was wrong and is required for this change. This isn't
considered a breaking change, as the SDK's minimum required version
isn't changed.

* Update arcade dependencies

* Remove NuGet pack tasks pkgref

* Add mega hack workaround

* Remove KnownFrameworkReference items

* Don't hardcode SDK value in helix submission...

* Update runtimeConfiguration.targets

* Fix double publishing error in mobile tests

* Set DotNetCliVersion to right version for aspnetcoreruntime

* Update sendtohelixhelp.proj

* Update sendtohelixhelp.proj
Co-authored-by: NSantiago Fernandez Madero <safern@microsoft.com>

This reverts commit c9fe433e.

* Fix installer build on Alpine

* Update src/tests/build.sh
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>
Co-authored-by: NViktor Hofer <viktor.hofer@microsoft.com>

Define PackageProjectUrl which is the public facing property to specify
a project url in a nuspec. Arcade defaults PackageProjectUrl to
RepositoryUrl if it isn't set. RepositoryUrl was incorrectly set to
git://github.com/dotnet/runtime instead of
https://github.com/dotnet/runtime which cause PackageProjectUrl to use
that incorrect value as well which ultimately results in nuget.org
failing package validation and refusing to add the package.

Also changing ProjectUrl to the previous https://dot.net value which is
the expected url to the dotnet project. In addition to that, specifying
Owners which aren't set anymore in 6.0.

Adding the ProjectUrl property as well as the
Microsoft.DotNet.Build.Tasks.Packaging package depends on it. That line
can be removed after the fix to not override its value unconditionally
is merged and consumed.

* Delete publish-final.proj and delete unused installer.tasks files

* Avoid extra restore phase for tasks

The repo local tasks don't participate in the repo restore anymore,
hence avoiding the extra restore phase which should improve reliability
and build times.

* Update incremental servicing condition for pkgs

* Move corehost under src/native

* Move content out of cli/ directory

* Update configurations post-move

* Update docs

Initial support for Mac Catalyst for mono subset. This enables building runtime packs and working jobs, but right now the `tests` subset needs some work to allow library test runs in CI

* Remove the src/mono/netcore directory, move its contents to src/mono.

* Fix docs and make targets.

* Remove the netcore dir itself.

* Fix samples.

* More packaging cleanup

* Add incremental package servicing throughout the repo

* Update dependencies to 6.0.0-beta.20630.3

* General cleanup and mono import Arcade in root

* More cleanup and coreclr import Arcade root

* Import Arcade root from libraries

* Set informationversion for corelib

* BuildArchitecture cleanup

* Fix property name

* Fix default target invocation of runtime.proj

* specify tfm correctly

* Remove unnecessary TestStrongNameKeyId

* Revert TestStrongNameKeyId removal

* Fix entrypoint target by using M.B.NoTargets

* Fix reference assembly paths

* PR feedback

* Set Platform correctly

* PR feedback and more cleanup

* Move BaselineMicrosoftNetCoreAppPackageVersion

* Fix reference to CoreLib

* Fix OS calculation

* Fix targets importing

* Remove *TargetOS

* Add RuntimeConfiguration doc

* Change conditions in root msbuild files

* installer test fixes

* Cleanup

* More cleanup because of well defined entrypoint

* Don't import D.B.* from installer tests at all

* Rename fix

* Include explicit reference to mscorlib in ilproj

* Update eng/restore/docs.targets
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Revert some installer test changes

* Installer test fix again

* Disable EOL tfm check for installer tests

* Set platform later for installer
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Consolidate packaging properties

* Remove versions.txt file from packages

The versions.txt file was added to packages to know which SHA a package
was built against. As the nuspec now contains the SHA, the versions file
isn't necessary anymore.

* Set IsPackable and validate PackageDescription

Now that the msbuild properties for the paths to these dlls are in the root Directory.Build.props we can remove the hardcoded paths.

December infra rollout - remove duplicated 'src' from coreclr subrepo (src/coreclr/src becomes src/coreclr) (#44973)

* Move src/coreclr/src/Directory.Build.targets to src/coreclr
Merge src/coreclr/src/CMakeLists.txt into src/coreclr/CMakeLists.txt

* Mechanical move of src/coreclr/src to src/coreclr

* Scripts adjustments to reflect the changed paths

This ensures they're built against net5.0 right now instead of net6.0.

* Consolidate RID and native file naming in MSBuild scripts
* Use short variable names for native files naming convention, that are
  used by `framework.sharedfx.targets` in arcade, and cleanup
  redefinitions from crossgen2 and installer. e.g. `ExeSuffix` instead
  of `ApplicationFileExtension`, `LibSuffix` instead of
  `LibraryFileExtension` and so on.
* Calculate `TargetArchitecture`, `NonPortableRuntimeOS` (for
  `PortableBuild`) and `PackageRID` values once for the entire
  livebuild, inside `eng/Configurations.props`. This implementation is
  a union of three varied implementations that are being deleted.
* Import `names.props` once in `eng/Configurations.props` based on
  calculated `PackageRID` and cleanup imports of this file from various
  places.
* Combine OS targets definition in MSBuild scripts.

* Delete legacy tooling properties

* Delete legacy tooling properties

* Add CoreCLR compilation support for Apple Silicon
    * Use CMAKE_OSX_ARCH rework
    * Set clang -arch flag
    * Workaround uname arch reporting emulated arch

* Fix native code compilation issues
* Implement missing osx-arm64 functionality
* Prototype fix for write no execute issues
* Strip libunwind pointer authentication bits

* Review feedback
* Does not fix Arm64 ABI issues
Co-authored-by: NJan Vorlicek <janvorli@microsoft.com>

When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:

1. The package maintainer builds code with the debug flags (such as
   `-g`) to generate full native debug info and symbols.

2. Nothing is stripped from build by the package maintainer.

3. The build system (`rpmbuild`, `debuild`) removes the debug
   info (or debug symbols) from the code and creates separate
   `-debuginfo` or `-debug` packages that contain just the debug
   symbols.

4. These debug packages are then distributed along with the normal
   packages using the normal Linux distribution mechanisms. This lets
   users install the exact set of debug symbols matching their other
   package.

To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:

    CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true

After this build, the built binaries include all debug symbols.

I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.

See https://github.com/dotnet/runtime/issues/3781 and
https://github.com/dotnet/source-build/issues/267 for more details on
the background and motivation.

For some related fixes, see:

- https://github.com/dotnet/coreclr/pull/3445
- https://github.com/dotnet/corefx/pull/24979

* Fix handling of repo analyzers and warnings-as-errors

When we brought in the new SDK, it enabled analyzers by default (which then used our custom ruleset), but a bunch of projects (in particular tests) weren't expecting that, such that we now have thousands of warnings in the repo. This opts-out those projects.

It also enables warnings-as-errors at the root level of the repo, to hopefully avoid such warning storms in the future, and to also clean up the remaining that exist.  This includes a bunch of new obsoletion and platform compat warnings that are firing in the runtime tests.

We may choose to run analyzers on additional projects in the future where it's currently disabled, but this gets us back to a state at least as good if not better than we were previously.

* Fix analyzer warnings on Microsoft.NET.HostModel

Fixes the warnings that were triggered by our rule set applying to this project.  All fixes were automated.

* Fix analyzer warnings in additional projects

* Remove several `<RunAnalyzers>false</RunAnalyzers>`

* Try to opt-out remaining coreclr tests
Co-authored-by: NDavid Mason <davmason@microsoft.com>

* Update SDK min and target version to >= Preview8

Add a subset for compiling only the wasm runtime: `mono.wasmruntime`
This allows us to rebuild the wasm runtime without building the full libraries subset.

Updated documentation with new guidance.

Updated how we build the dotnet.timezones.blat.

* Incorporate timezone data from runtime-assets
* Change CreateWasmBundle name & create separate timezones.props file

Add two build tasks:
1. DownloadTimeZoneData 
2. CreateWasmBundle (given directory bundle files into a data archive)