Introduce _id keyword for manually giving testitems a stable identifer

[nickrobinson251]

if the testitem name is being automatically set to something liable to change, e.g. file:line location of the testitem, then for the sake of reporting you might want to automatically attach an identifier that's less liable to change (while still keeping the more informative name for the sake of logging).

Part of https://relationalai.atlassian.net/jira/software/c/projects/RAI/issues/RAI-13793

[quinnj]

So is the idea here users can provide an id="XYZ" keyword arg to uniquely identify, but they don't have to provide a name? Are we doing any checking that the provided id is actually unique vs. all other parsed test items?

[nickrobinson251]

currently, testitems must have a name, and always have a file, and for the same file every name must be unique... so file/name is a unique identifier... and relatively stable (people don't change the name of a test, or move tests between files very often)

But, if you know that you're setting a name that is very liable to change, e.g. you're setting it to be the line number, then we provide the option of passing a id keyword as well as a name. That way, you can take control of setting a more stable identifier, without having to change the name. It's super niche to our internal use-case:
the @test_rel (unfortunately) doesn't require a name, so when turning it into a @testitem we're automatically setting the name to as file:line e.g. foo_test.jl:42, we want this name to be somewhat informative, hence picking file:line, but we also want a way to track tests over time (and line numbers change very often, especially when we have files that have hundreds of tests, and are not append-only), so we're thinking of setting a separate id that's a hash of the test's actual contents (which should not change often): https://github.com/RelationalAI/raicode/pull/14338

[quinnj]

Sounds good; thanks @nickrobinson251! I wonder if we even call it something like _id just to try and emphasize that this really shouldn't be needed in the non-us case.

[nickrobinson251]

Are we happy throwing on this? I suppose hash collisions are possible, right?