RemixApi: add AddTextureHash and RemoveTextureHash methods

[xoxor4d]

This is one part of the PR that covers both the bridge and the runtime. The bridge PR can be found here:
NVIDIAGameWorks/bridge-remix#17

This PR implements two new API methods: AddTextureHash and RemoveTextureHash.
These can be used to add or remove individual texture hashes from texture category options (hash sets).
The SetConfigVariable is not practical in that regard as it only allows to set the entire option to the specified value and would require the user to craft the entire hash set string.

Example use cases:

• Some effect or similar that is using texture XY is causing issues on a certain map and has to be hidden. But texture XY is also used in other parts of the game where it does not cause issues.
• Multiplayer/Coop games where the player character is visible in first person view (and tagged as player body) to allow for shadows or virtual instances (Portal) but the player model changes based on the class/team etc. Prime example would be Portal 2 Coop where two different player models are in use. The two methods allow me to dynamically set/remove the player body texture hashes depending on which character you play.

Notheworthy changes:

• increased REMIXAPI_VERSION_MINOR from 5 to 6

Included fixes:

• fixes mismatching remixapi_InstanceCategoryBit enum (runtime issue #727) ([Runtime Bug]: remixapi_InstanceCategoryBit does not match InstanceCategories rtx-remix#727)
• fixes bridge issue #736 ([Runtime Bug]: NRC runtime crashes when using RemixApi from Bridge rtx-remix#736) that was caused by outdated api headers in ext/remix/.

2025-03-18.21-25-29.mp4

if (ImGui::Button("Add Hash")) {
	remix_api::get()->m_bridge.AddTextureHash("rtx.ignoreTextures", "0x990C1CCB42F806E0");
}
if (ImGui::Button("Remove Hash")) {
	remix_api::get()->m_bridge.RemoveTextureHash("rtx.ignoreTextures", "0x990C1CCB42F806E0");
}

[nsubtil]

REMIX-4052

[MarkEHenderson]

Changing the order like this will break any existing uses. I know it's just making it match the order of InstanceCategories in the runtime, but making the code slightly nicer isn't a good reason to introduce a breaking change to the API.

[MarkEHenderson]

New functions need to be declared at the end of the struct to preserve backwards compatibility

[MarkEHenderson]

patch version should be reset, since you bumped the minor version. (0.5.1 becomes 0.6.0, not 0.6.1)

[MarkEHenderson]

The arguments we used for SetConfigVariable are actually something we regret, and we'd like to avoid repeating the same mistake. Primarily, in that it would be a breaking change to add any more arguments.

Instead of AddTextureHash and RemoveTextureHash, we'd prefer to see a ModifyRtxOption function that takes in a struct. That struct can be extended without breaking backwards compatibility, and could have fields for adding & removing values from a HashSet.

typedef struct remixapi_ModifyRtxOptionArgs {
    remixapi_StructType sType;
    void*          pNext;
    const char* rtxOptionName;
    const char* newValue;

    // Hash value to add or remove.  Only used if `rtxOptionName` is a HashSet and `newValue` is a nullptr.
    // Value of 0 is a no-op.
    uint64_t       hashToAdd;
    uint64_t       hashToRemove;
} remixapi_ModifyRtxOptionArgs;

May also be a good idea to define a REMIXAPI_EMPTY_HASH that's set to 0 somewhere in the API, instead of just having 0 as a magic value in that comment.

There may be a better way to encode newValue that would support actual int/float/etc values, but