Add support for reading / writing string attributes

[nosoop]

メリークリスマス

This PR introduces string attributes through the following changes:

• New native TF2Attrib_SetFromStringValue, which takes an attribute name and value string and performs any appropriate internal conversions (uses the same logic that the game uses for schema key / value parsing into values) and applies it as a runtime attribute.
  • The design for that native is intended for errors to be handled or ignored on the caller, instead of forcing them to perform pre-flight checks. They should just be able to pass in a key / value pair and find out if it was successful or not after the fact.
• New native TF2Attrib_GetStringValue, which takes a string attribute name and returns the first valid string value it finds for that attribute on an entity (prioritizing attributes applied on runtime, GC, then static).
  • See comment further down in this PR; this native has a successor.
  • This native was removed.
• New native TF2Attrib_UnsafeGetStringValue to read arbitrary attribute string values instead of following the priority rules above.
• An internal heap-tracking system that manages heap-allocated runtime attributes. The game doesn't manage such things itself (it only does this for GC and static attributes). This needs a bit of work, but it should be fine as-is for getting this out the door (future work would include be deduplicating strings and cleaner unload logic).

The potential use cases for this include:

• Reading custom name / descriptions off weapons.
• Overwriting server-sided string attributes (this can be used to set override projectile model).
• Replacing nosoop/SM-TFCustAttr by using an attribute injection method such as Hidden Dev Attributes.

This bumps up the minimum required SourceMod compiler version to 1.10. I could backport the one enum struct that is used, but I think we should be fine not targeting anything older than the current stable release.

This supercedes and closes FlaminSarge#41.

Mainly self-PRing this to CC @FlaminSarge for review, gotta make sure the API design looks fine

[nosoop]

This one was a doozy.

The latest commit adds TF2Attrib_HookValueString, which behaves similar to the other TF2Attrib_HookValue* natives — it takes advantage of the game's caching system and takes an attribute class instead of a specific attribute name.

It somehow Just Works™ on strings applied as runtime attributes (even though they can't be synchronized across the client/server divide).

Some preliminary micro benchmarks indicate that TF2Attrib_GetStringValue can be 1.5x or 18x (eighteen times) slower in comparison (the latter being the case where an item doesn't contain an attribute, as it has to iterate over every form of attribute list on every invocation; the microbench also only operates on clients, so item server / static attributes aren't even considered).

So at this point TF2Attrib_GetStringValue has been deprecated. It may even be removed before the PR gets merged, since anything here isn't actually finalized yet.

In case you need to migrate between development versions, here's what you need to change:

#define ATTRIBUTE_NAME  "custom name attr"
#define ATTRIBUTE_CLASS "custom_name_attr"

TF2Attrib_GetStringValue(entity, ATTRIBUTE_NAME, buffer, sizeof(buffer));
TF2Attrib_HookValueString("", ATTRIBUTE_CLASS, entity, buffer, sizeof(buffer));

[nosoop]

🦀 TF2Attrib_GetStringValue is gone 🦀