FR: Make jj annotate extendable with blame layers

[PhilipMetzger]

This is extracted from #2988 as it was closed after the jj annotate command got added.

Since there are many systems like Codesearch or Codereview tools which want to integrate with jj-lib we should provide something like a blame layer abstraction, which allows each user to fetch only the necessary information they need.

A better description from a previous comment of mine:

A problem I have with git is it shows too much metadata by default, making it harder to browse

• Who made the change doesn't matter as much as the change itself. From there, I can find out who made it
• Knowing the time is good but it is hard to tell the time relation between two lines to know which happened first
• I'm not going to remember a commit hash for doing things off of; it is only good for copy and paste which slows me down

Yes, that's the goal of having a abstract interface for the UI of jj annotate/jj blame as many different systems interact with the commit metadata. This then allows us to build different layers for each use-case, such as commit metadata only, the structural diff and more. Then each effective backend can compose its functionality with the different blame layers, as maybe your internal codesearch tool only wants the author and the related metadata when it landed.

As I use a merge-commit workflow on multi-commit PRs, I find having the code only annotate for the merge-commit is both more informative (giving me the context of the logical series its attached to and a quick reference for the PR to open it to see the review) and speeds things up.

If you can write a blame layer for your use-case, I'd be happy to accept it.

[yuja]

only annotate for the merge-commit

For this use case, I think the ancestors to be searched can be filtered by revset. (e.g. jj file annotate --start=REV --within="merges()" or ancestors(nth_parent=1).) I'm going to add internal API to calculate annotation within "absorb" destinations.