Add an option to pack some resources to an archive automatically

As discussed [here](https://discord.com/channels/728582275884908604/801658049244430377/813388882712068136), it can be a resource processing plugin.

Actually, I currently do a similar thing in my project: I have a special task that takes files from `resourcesRoot` dir and creates `src/commonMain/resources/resources.zip` archive:

```kt
// https://github.com/SerVB/pph/blob/027db948693c09a92ceab6adc3c2dff973194eb3/build.gradle.kts#L36-L50

val compressedResourcesFile = rootProject.file("src/commonMain/resources/resources.zip")

tasks.create("packResources") {
doFirst {
compressedResourcesFile.delete()
compressedResourcesFile.parentFile.mkdirs()
}

from(rootProject.file("resourcesRoot")) {
include("**")
}

archiveFileName.set(compressedResourcesFile.name)
destinationDirectory.set(compressedResourcesFile.parentFile)
}
```

After it, I just create `rootVfs` variable and use it everywhere in my game:

```kt
// https://github.com/SerVB/pph/blob/027db948693c09a92ceab6adc3c2dff973194eb3/src/commonMain/kotlin/main.kt#L8-L19

val rootVfs = resourcesVfs["resources.zip"].openAsZip(caseSensitive = false) // case insensitive to avoid strict matching
```

It's useful when the game has many resources but should be playable in a web browser: only a single file with resources is loaded, and it's relatively fast.

So let me describe a concept of "big resources" (the name is yet to consider).

I think KorGE could pack this special resources set automatically when a special option is set in Gradle build script (it can be even a default behavior of using packaging, and behavior of using plain files in the resources can be set up manually). Also, it's better to not have that `rootVfs`, so need to provide something like `bigResourcesVfs` by KorGE to use them right away.

So possible usage can be as follows:

```kt
// build.gradle.kts

korge {
//...

bigResourcesStrategy = PackCaseSensitiveZip // other available variants: PackCaseInsensitiveZip, CopyFiles
}
```

After it, `src/commonMain/resources` will stay as they are now: they will be unpacked and can be loaded very fast. It can be useful for resources like logo icon that should be available from the very start so it's needed to load it fast. Many games can continue to use only plain resources. And big resources will be useful if the game has many files or big compressible files, this can be used by some games to simplify the distribution.

Moments to consider:
1. I don't like "big resources" name much, maybe someone can propose a better one.
1. Maybe some more archive formats should be implemented. The drawback of Zip is that it uses per-file compression that can be not as efficient as the full volume compression. On the other hand, I hope it gives better decompression speed, particularly getting the list of files in Zip should be relatively cheap. This can be considered later if there is demand, I'm OK with Zip.
1. Which dir to choose? Mine `resourcesRoot` is kinda temporary solution, maybe something like `src/commonMain/bigResources` is better.
1. I think it will be handier to merge `bigResourcesVfs` to `resourcesVfs` (so `bigResourcesVfs` won't be introduced), if it's possible. However, then it's needed to check for collisions in file names in compile time.
1. Maybe it should be more flexible and allow defining different archives (like resources-for-level-1.zip, resources-for-level-2.zip and so on), but I think again it can be considered later if there is demand.

I'll be glad for any ideas and comments. By the way, where is the code of KorGE that copies the resources (probably somewhere in KorGE Gradle plugin)? I think I can try implementing it and sending a PR.

Start by locating the KorGE Gradle plugin code that copies resources, then review the build.gradle.kts example and the resourcesRoot and src/commonMain/resources paths. Define the supported packing strategy and resource access behavior, including how archives are exposed through resourcesVfs or a separate VFS, and document the chosen directory and collision rules.

Written by the indexing model from the issue text.