Add codes to MSBuild warnings and errors

[natemcmaster]

Follow-up to this: #2064 (comment)

Most MSBuild warnings and errors issued by this SDK do not have error codes. We should add codes to all of them.

[nguerrera]

Moving to 2.1.4xx because there's a 15.8 project system feature that needs to light up on a well known code. I want us to establish a convention that we can follow moving forward and close on this. I don't want to pick one code for the particular error that project system will need and then get stuck with that being different when we finally make a decision for all error codes.

Here is my straw man proposal:

NETSDK1001
NETSDK1002
etc.

I chose NETSDK because the errors are generated by our code referenced as "Microsoft.NET.Sdk".

That said, the particular error needed now is generated from a separate component in this repo: the ".NET Framework extensions". How about this for that component:

NETEXT1001
NETEXT1002
etc.

I'm open to other prefixes and starting numbers. For example, we could use DOTNET for everything. If we do that, we may need to be careful to avoid collision with DOTNETNNNN errors from the project.json era CLI. Does the CLI still issue it's own codes elsewhere? If so, it would probably be best to use different prefix for things from the build tasks and the CLI to prevent unintentional collision risk.

cc @KathleenDollard, @livarcocc, @dotnet/dotnet-cli It would be very helpful to close on this quickly to unblock @tmeschter

[KathleenDollard]

I would expect the number one consideration to be avoiding collisions, followed by clarity (perhaps stating the obvious).

I like the prefix and the simple number - not more than six digits, four is nice.

I do not think we should use DOTNET for everything. It seems doomed to collisions.

[nguerrera]

So it turns out that the extensions and the sdk proper share a resx file and can issue the same messages. As such, it would actually be easier for them to share a prefix that we just increment whenever we add a new one regardless if extensions or Microsoft.NET.Sdk or both issue it. NETSDK isn't entirely accurate for both, but that's probably a technicality that doesn't really impact any user experience.

My proposal is now:

NETSDK1001
NETSDK1002
etc.

For any error or warning that originates from the source code in this repo.

[nguerrera]

Fixed by #2269