feat: Scan wildcard subdirectories

[Cruxial0]

Closes #2461

Allows users to sort their wildcards in folders. Previously Fooocus would only search the base directory.

• Implements functionality for scanning subdirectories within the wildcards directory
• Adds a function for returning the first occurrence of a file within a directory tree

[mashb1t]

@Cruxial0 i've added the ability to configure wildcards filepaths incl. caching as the wildcard filepaths were collected every time a wildcard was processed (in the max. 64 iterations for loop).
Please double check so we can merge this feature to develop for the next release.

[Cruxial0]

Please double check so we can merge this feature to develop for the next release.

Looks good, however I'm not sure how much I like having to refresh files every time a wildcard is added. When I work with wildcards, I tend to add new files frequently. It's by no means a deal-breaker, but I believe it would be more user friendly to update it automatically. Maybe a function that compares the number of files in the wildcard directory at the start of every generation, and only updates if files were added/removed?

[mashb1t]

@Cruxial0 the options are

• cache content of wildcards, access cached array only => least flexible, but most performant. Downside: linear increase in memory consumption depending on file content of wildcards
• loading files in apply_wildcards => loaded for each image number iteration
• same handling as styles_files => only loaded on application start
• method called before apply_wildcards outside the task loop => list needs to be collected for every generation click
• store file list in config, reload with reload files button => one time file list processing, allows dynamic content changes while still offering reload without having to restart Fooocus

The changes of this MR now also allow nested directory structures and recursive collection, which is why file counting is not going to work, also one file can be deleted and another added, which is why a simple count isn't sufficient here.

I think the currently implemented option offers the best compromise between performance and flexibility.