Add RequiresAssemblyFiles attribute

[agocke]

This PR annotates every API doc'd as having different
behavior in single-file publishing with RequiresAssemblyFiles.
Some APIs might be special-cased by the analyzer to produce
special messages, but RAF is useful for visual inspection
of the APIs. Module.Name and .FullyQualifiedName were also
unannotated.

Docs: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file

Assembly.Location | Returns an empty string.
Module.FullyQualifiedName | Returns a string with the value of <Unknown> or throws an exception.
Module.Name | Returns a string with the value of <Unknown>.
Assembly.GetFile | Throws IOException.
Assembly.GetFiles | Throws IOException.
Assembly.CodeBase | Throws PlatformNotSupportedException.
Assembly.EscapedCodeBase | Throws PlatformNotSupportedException.
AssemblyName.CodeBase | Returns null.
AssemblyName.EscapedCodeBase | Returns null.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[jeffhandley]

@buyaa-n This PR is assigned to you for follow-up before the RC1 snap.

[agocke]

@buyaa-n anything else?

[buyaa-n]

Left two minor comments, overall LGTM

[agocke]

@buyaa-n If you wouldn't mind taking another look, I found some more missing annotations, and an inconsistency in casing that I've tried to fix up.

@VSadov @vitek-karas for change in casing in runtime. In theory this could be a breaking change for people upgrading from .NET 5 to .NET 6 but I think the inconsistent casing meant it was impossible for them to rely on specific behavior in this situation anyway. I'd rather settle on one casing for .NET 6.

[jkotas]

for change in casing in runtime. In theory this could be a breaking change for people upgrading from .NET 5 to .NET 6 but I think the inconsistent casing meant it was impossible for them to rely on specific behavior in this situation anyway.

I believe that the runtime reflection APIs have been consistently returning uppercase <Unknown> for images loaded as byte arrays since forever. I am not sure why you think it was impossible for apps and libraries to depend on this specific behavior.

[agocke]

OK, I think this is finally up-to-date. I ended up finding a questionable behavior in single-file for Module.ScopeName which needs to be investigated separately. I filed #56519 to track that. I'd rather address that separately than block the rest of this PR on that small issue.

[agocke]

@buyaa-n Anything else? I think the one tricky bit I've filed an issue for, so we can come back to it later.

I took Jan's advice and changed the casing of <unknown> to <Unknown> for MetadataLoadContext, so it now matches the years-old behavior of the runtime.

[buyaa-n]

One NIT comment, overall LGTM