Add abbreviation column to the table links

[jarofromel]

Some of links are defined with the abbreviation. The link abbreviation is not present in the table links only the original link type. For example

* link defined as abbreviation
- [[wikipedia:Statistical_distance]]

which is defined in the org-link-abbrev-list as:

            '("wikipedia"   . "https://en.wikipedia.org/wiki/%s")

is stored without the abbreviation:

Not important. Just nice to have there a new column with the abbreviation as well.

Use case: I use the abbreviation as a kind of metadata, e.g. for the same page I use more abbreviation (wiki_note, wiki_ref, wiki_quote).

#17 describes the way I get here.

[ndwarshuis]

I haven't looked into this fully yet but at least limited abbreviation (that is, without any substitutions using %h and %s) shouldn't be hard to add to a new column

[ndwarshuis]

I added partial support in 140a9f78435def29235139cd4fcc94fe4db06ec1. Please test and see if this works for you.

Regarding why this is only 'partial', org-element will expand link abbreviations by itself, which means org-sql only sees the expanded link and thus must do a reverse lookup in org-link-abbrev-alist. This isn't a problem if the final expanded link has an exact match, but anything with %s or %h won't work because the tag information that subs into these replacement keys is effectively destroyed by the time the link reaches org-sql. Of course there's hacky ways around this, but nothing I can come up with is very clean or performant.

[jarofromel]

I tested with the following results:

1. new column link_abbrev is visible in the links table
2. only NULL value is there, i.e. no abbreviations were found in my org mode notes
   • the value of org-link-abbrev-alist in my org config is non nil:

     (("goodreads" . "https://www.goodreads.com/book/show/%s")
     ("doomdir" . "/home/random/.doom.d/%s")
     ("doom-repo" . "https://github.com/doomemacs/doomemacs/%s")
     ("wikipedia" . "https://en.wikipedia.org/wiki/%s")
     ("google" . "https://google.com/search?q=")
     ...)

I'll inspect 2) furthemore.

Regarding the expansion I think the current solution is OK. The link abbreviation in the table tells me which logic was applied during the expansion (because the expansion logic is defined in the org-link-abbrev-list), thus I can reconstruct it by custom SQL (reversing the expanded link_path)