Use WebRootFileProvider to load in package manifests - reducing boilder plate code for RCL packages

[KevinJump]

Similar to #12313

If you are using a Razor Class Library (RCL) for your package, the package.manifest file is not automatically loaded by Umbraco, and you have to load it via code in your library.

If we could use a IFileProvider when loading the packages in the app_plugins folder, there wouldn't be the requirement for people to have to write boiler plate code to initialize their package manifests.

At the moment you had to either define a IManifestFilter in code and add it via a composer
or embed the package.manifest as a resource in your project, load it and parse it again in a composer.

if the package.manifest could be read directly from RCL 'app_plugins' folders this would make this step redundant. and mean we could have 'no-code' packages using the RCL pattern.

Change required:
I think the the only change required is to the GetManifestFiles method in the Manifest parser.

https://github.com/umbraco/Umbraco-CMS/blob/v10/dev/src/Umbraco.Infrastructure/Manifest/ManifestParser.cs#L201-L209

  private IEnumerable<string> GetManifestFiles()
  {
      if (Directory.Exists(_path) == false)
      {
          return Array.Empty<string>();
      }

      return Directory.GetFiles(_path, "package.manifest", SearchOption.AllDirectories);
  }

Something similar to the code used in the Lang file PR (not this isn't tested just example of change)

var pluginFolders = fileProvider.GetDirectoryContents(_path)
        .Where(x => x.IsDirectory).ToList();

foreach (IFileInfo pluginFolder in pluginFolders)
{
    // get the full virtual path for the plugin folder
    var pluginFolderPath = WebPath.Combine(folder, pluginFolder.Name);

    IEnumerable<IFileInfo> manifestFiles = fileProvider.GetDirectoryContents(pluginFolderPath)
        .Where(x => x.Name.InvariantEquals("package.manifest"));
}

Only issue is like with the Lang files, the Manifest parser is currently in the Infrastructure project and we can't inject IWebHostEnvironment into the parser where it is.

Not sure what the options should be here, but happy to do the PR if someone can tell me what if anything should be done/moved.

[p-m-j]

I think the reasonable thing to do here is to:

1. Mark the existing ManifestParser class as obsolete, it's public so maybe someone downstream is subclassing it.
2. Create a new implementation (preferably as an internal class) in Web.Common Web.BackOffice
3. Switch over the registration into the container.

Edit: Alternatively separate out the parsing from the IO, have an additional interface for PackageManifestLoader or similar which the Parser can delegate to that returns a collection of TextReaders.

Edit 2: I think I like both ideas combined a ManifestParser and a ManifestLoader both in Web.Common Web.BackOffice :)