Move HttpUtility to System in unityjit.

[joncham]

This change moves HttpUtility and a few helpers from System.Web to the System assembly. The reduces the dependencies of netstandard.dll greatly. This makes it easier for us to enable Mono players to always use the unityjit profile even with API compatibility level of ".NET Standard 2.0". The build size will increase slightly, but much less than without this PR. For example, we have a test today where netstandard.dll pulls in the following extra assemblies when targeting unityjit rather than unityaot

Trunk:

"assets/bin/Data/Managed/System.Design.dll",
"assets/bin/Data/Managed/System.Web.ApplicationServices.dll",
"assets/bin/Data/Managed/System.Windows.Forms.dll",
"assets/bin/Data/Managed/System.Drawing.Design.dll",
"assets/bin/Data/Managed/Mono.WebBrowser.dll",
"assets/bin/Data/Managed/Mono.Posix.dll",
"assets/bin/Data/Managed/System.Runtime.Serialization.Formatters.Soap.dll",
"assets/bin/Data/Managed/System.ComponentModel.DataAnnotations.dll",
"assets/bin/Data/Managed/System.Web.dll",
"assets/bin/Data/Managed/System.Web.Services.dll",
"assets/bin/Data/Managed/System.Security.dll",
"assets/bin/Data/Managed/Novell.Directory.Ldap.dll",
"assets/bin/Data/Managed/Accessibility.dll",
"assets/bin/Data/Managed/Mono.Data.Sqlite.dll",
"assets/bin/Data/Managed/System.DirectoryServices.dll",

With this PR:

"assets/bin/Data/Managed/Mono.Posix.dll",
"assets/bin/Data/Managed/System.Security.dll",

Which I think is acceptable.

A type forwarder is setup to not break compatibility. Note, there are two small changes in behavior. The defines in HttpEncoder.cs and HttpUtility.cs hardcode some things rather than using System.Configuration. I think this is okay as we already do this in the unityaot profile.

[joncham]

Note, I would do this same work for the upgrade branch if we think it makes sense to land this.