[GR-49770] Restrict the Expressivity of Patterns in `resource-config.json`

[vjovanov]

TL;DR

Native Image currently accepts Java regular expressions as file patterns in resource-config.json. This is problematic for two reasons:

1. It is error-prone as users often miss simple patterns in resources: The errors are common due to wrongly written (or missing) \\Q and \\E characters.
2. It is computationally demanding to check if a query that does not hit a resource should throw a MissingResourceRegistrationError or return a null. With regular expressions, it is necessary to check all regular expressions in the build against the current resource path.

In this proposal, we restrict the resource-matching patterns to a subset of the glob patterns to simplify pattern matching and reduce computational complexity. The patterns that would be supported are:

1. The * pattern that matches any number of characters including none within the current directory.
2. The ** as a name component to recursively match any number of layers of directories.

Proposed patterns allow users to write queries to bulk-include resources, for example, assets/**/* or images/**/*.png. However, they can be canonicalized into a tree-like structure that allows fast checking of negative queries at run time.

The new format will allow only the inclusion patterns:

{
  "resources": [
      {
        "glob": "assets/**"
      },
      {
        "module": "myJavaModule",
        "glob": "images/**/*.png"
      }
  ]
}

Goals

1. Simplify resource patterns to make writing of resource patterns easier.
2. Reduce the cost of run-time checks for negative resource queries.

Non-Goals

1. Make resource-pattern writing harder.
2. Disallow matching multiple resources with one entry in resource-config.json.

Backward Compatibility

The new format will be output by the agent and described in all documentation as the default. The reachability metadata will be migrated to the new format when the JDK 17 and JDK 21 version adopt the back-ported support for this feature.

The current format for resources will be supported until the majority of the ecosystem adopts the new format.

[olpaw]

I support the idea of using globbing instead of allowing arbitrary regex for resource inclusion.

However, we should ensure that this new format also allows per-module resource inclusion like the current format. See:

graal/docs/reference-manual/native-image/Resources.md

Line 102 in 5cfb880

### Resources in Java Modules

This new format give us the opportunity to have a dedicated field for per-module resource inclusion instead of encoding an optional module-name prefix into the pattern name like we did before.

[olpaw]

Also we should not break compatibility with the existing regex based solution but instead deprecate it. I.e. whenever we see a resource-config.json with some json substructure in resources/include or resources/exclude we emit a warning message that we will remove support for pattern-based resource inclusion in the future.

That requires that we use a different json substructure for the new resource inclusion approach. E.g. something like

{
  "include": [
      {
        "pattern": "assets/**"
      },
      {
        "module": "myJavaModule",
        "pattern": "images/**/*.png"
      }
  ]
}

that would not conflict with the existing data because there we do not allow "include" on top-level right now.

[vjovanov]

I fully support the idea of the module field here. I would just not use the "include" at all. The resources with an array should signify that the file uses a new pattern. I will update the description.