FR: Add external log context into jj log

[entropitor]

Is your feature request related to a problem? Please describe.
jj log is a really nice graph format that you can tweak to your liking, except for the fact that only jj-specific information is available. It would be nice to integrate external data (CI status, PR status, ...) into the graph

Describe the solution you'd like
Allow piping json (?) to stdin with a mapping from change-id to extra "context" and then expose a context field on the changeId for templates so it can be nicely included in a script.

Describe alternatives you've considered
Scripts can parse output of jj log and try to reconstruct a graph but it's hard to have the same graph like structure and sometimes it's small changes where this feels overkill

Additional context
Maybe the passing in should also include the type, e.g. something like

{"change": {"ltuonvqquknk": {"foo": "bar"}}, "commit": {"dc4adbf5": 42}}

so other types also can gain context.

Not sure if stdin is the best way to pass this context in

[bnjmnt4n]

Related: #6664.

[josephlou5]

I sort of work around this by mapping a commit id (or change id if the info isn't constrained to a specific commit) to <some random info> in the repo config. For example:

[pr-links]
xnxkvywvtrsx = "1234"

I also wrote a script to populate these values on certain actions, such as push, but you can manage them manually too. Then you can use the config() function to access values in templates.

Big caveat: the config() templating function only accepts a string literal, so you can't do config("pr-links." ++ self.change_id()) (don't know if there's an FR for that tho). Instead I had to do if(config("pr-links"), json(config("pr-links")).remove_prefix("{").remove_suffix("}").replace('"', '').split(",").map(|x| if(x.starts_with(self.change_id() ++ ":"), x.remove_prefix(self.change_id() ++ ":"))).filter(|x| !!x).take(1) or something to that effect lol (basically parse out the relevant line because maps aren't a type in the templating language; #7697) (this is untested). Due to current constraints, this also means that the mapped values are pretty limited; I only used them to store numbers or other commit ids, so didn't personally run into problems with quotes or commas. This also does not scale since all the data is stored forever, but of course you could clean it up periodically as well. Use at your own discretion.

Also with the change in v0.38.0 of repo configs being stored outside the repo itself, this feels like a less desirable solution since this "hidden metadata" feels more visible now. But that's up to each user's own preference I suppose.