SDL3 Proposal: Title/user open-storage functions can create containers rooted relative to their default/overridden root

[nightmareci]

I've run into an issue with the storage APIs that prevents a certain usage pattern that I'd like to be supported: Being able to create title/user storage containers rooted at a path relative to the default/overridden storage root.

If such a feature were supported, the following storage setup would be made possible:

The user can define a function, OpenDataStorage(), that returns a storage container rooted in a data subdirectory of the default storage root (the root used in SDL_OpenTitleStorage(NULL, 0)), e.g.:

// Windows
SDL_Storage *OpenDataStorage(void)
{
    SDL_PropertiesID props = SDL_CreateProperties();
    SDL_SetStringProperty(props, SDL_PROP_STORAGE_RELATIVE_ROOT, "data/");
    SDL_Storage *storage = SDL_OpenTitleStorage(NULL, props);
    SDL_DestroyProperties(props);
    return storage;
}

But for some platforms, it's appropriate to use an absolute location override in the native path format, like a Linux package manager installation of a game (as usual, in the real implementation, you'd use some #ifdef stuff that implements the right style per platform, or build system logic), e.g.:

// Linux package manager
SDL_Storage *OpenDataStorage(void)
{
    // The storage-relative-root property would be supported in combination with an override, but isn't used here.
    return SDL_OpenTitleStorage("/usr/share/game_name/", 0);
}

So now, either style can support a secondary title-storage-based storage container for documentation files separate from game data, e.g.:

// Windows
SDL_Storage *OpenDocumentationStorage(void)
{
    SDL_PropertiesID props = SDL_CreateProperties();
    SDL_SetStringProperty(props, SDL_PROP_STORAGE_RELATIVE_ROOT, "docs/");
    SDL_Storage *storage = SDL_OpenTitleStorage(NULL, props);
    SDL_DestroyProperties(props);
    return storage;
}

// Linux package manager
SDL_Storage *OpenDocumentationStorage(void)
{
    return SDL_OpenTitleStorage("/usr/share/doc/game_name/", 0);
}

Now, you can ship a game with an "appropriate data layout" for each platform, with the documentation files provided "the right way" per platform, and the game itself able to access the documentation, for presenting the documentation in-game, like LICENSE.txt or README.txt. And this allows the game's code to use the same storage paths for all ports with the data/documentation containers ("write once run everywhere" principle), regardless of how the storage root per container is set up per platform.

The storage-relative-root property would be supported for user storage (SDL_OpenUserStorage()) as well. That'd be handy for end-user-installed mods.

This proposal works with the current ABI, requires no new functions, and makes no change to the current behavior of the title and user storage functions.

Edit: For setting user storage root, it'd probably be appropriate to create the indicated directory, if it doesn't exist.