Add configurable texture output folder for appearance export

[yaozhihang]

Currently, textures are always exported to the fixed default relative folder appearance. This PR adds a new textureOutputFolder option to AppearanceOptions, allowing users to customize the relative folder where exported textures are written.

[clausnagel]

Hi @yaozhihang, I have a few questions:

1. What is the rationale behind this PR? I think a stable output folder has benefits.
2. How does this behave if the user specifies an absolute path, such as /myfolder or C:\myfolder?
3. How does it handle paths that include subdirectories, such as my/nested/folder?
4. Does this also work when exporting to a ZIP archive?

[yaozhihang]

Hi @yaozhihang, I have a few questions:

1. What is the rationale behind this PR? I think a stable output folder has benefits.
2. How does this behave if the user specifies an absolute path, such as /myfolder or C:\myfolder?
3. How does it handle paths that include subdirectories, such as my/nested/folder?
4. Does this also work when exporting to a ZIP archive?

1. The main purpose is to allow exporting data into the same output folder while keeping textures from colliding within a shared appearance subdirectory. This is needed by my vis-exporter, which will reuse the citydb-operation module. The default still use appearance, so existing behavior is unchanged.
2. It is true that the absolute path will not work properly. How about adding the following guard code into the constructor of the TextureExporter?

        Path baseDirectory = helper.getOptions().getOutputFile().getFile().getParent();
        if (baseDirectory != null
                && !baseDirectory.resolve(outputFolder).normalize().startsWith(baseDirectory)) {
            throw new IllegalArgumentException("The texture output folder must be a relative path "
                    + "inside the export target, but was '" + outputFolder + "'.");
        }

4. Subdirectories work without problems, and this also works when exporting to a ZIP archive.

[yaozhihang]

@clausnagel I found another workaround to avoid touching this API. We could close this PR if you think a hard-coded output texture folder is necessary

[clausnagel]

Sounds good. I'll close this for now, but feel free to reopen it if you'd like to continue the discussion.