Somehow distinguish .js files that are static web assets from those that are Windows Script Host scripts

**Is your feature request related to a problem? Please describe.**
We recently had a bug reported for a Blazor nuget package that was causing an integrity conflict and failure during development when that package was consumed (reference: https://github.com/IgniteUI/igniteui-blazor/issues/267)

Since by default, the `sign` tool treats NuGet packages as archives/containers and strives to apply code-siging practices to as many of the contents as possible, the problem is that for ASP.Net Core / Blazor-related NuGet packages that contain static web assets - `.js` files - the integrity of each file is recorded at build time in the `Microsoft.AspNetCore.StaticWebAssets.props` file.

However, if using the `sign` tool's default options, the `.js` asset files get changed and in development mode, the SHAs of the signed `.js` files mismatches those of the pre-recorded SHAs of the files prior to signing.

**Describe the solution you'd like**
I can imagine that considering .js files to be static web assets or WSH scripts is out of scope of the sign tool's logic, but may be it isn't.
Either identify and omit .js files that are static web assets or at least throw a warning that such have been found and need to be excluded by either the --file-list option or outright using `--recurse-containers false`.

**Describe alternatives you've considered**
Even though it's useful to have all DLL files signed along with the containing NuGet packages, we resorted to using `--recurse-containers false` so that the .js web assets remain untouched. We are signing the DLL files prior to packaging the .nupkg file - just like when using the signtool.exe.

**Additional context**
sign tool version = 0.9.1-beta.26330.1+89c2a5d4a051014c243779d174bc3bb1fca62d7d

Start by reviewing the sign tool's default container recursion and the --file-list and --recurse-containers options, then reproduce the issue with an ASP.NET Core or Blazor NuGet package containing .js assets. Done means the tool has a defined way to preserve static web assets or clearly warns users how to exclude them without affecting other files.

Written by the indexing model from the issue text.