feat: add type metadata and subcommand for clipboard entries

[xeorain]

Motivation

When the output of cliphist decode is piped to wl-copy, wl-copy needs to
determine the MIME type of the input data. Currently, wl-copy invokes xdg-mime to infer the MIME type, while allowing the --type option to specify a MIME type explicitly instead of relying on the internal inference. However, there are edge cases where plain text data is incorrectly identified as a non-text MIME type by wl-copy.

See: bugaevc/wl-clipboard#294

Changes

This patch simply prepends a 1-byte type indicator header to the stored clipboard data to distinguish text data from binary data. Values are now stored in the form of [type-indicator][payload] in the database.

The cliphist type <id> command can be used to query the type of a stored
clipboard entry by its record id, allowing the clipboard restoration scripts to provide a more accurate MIME type to wl-copy. Below is a typical example of
the usage:

item_type="$(cliphist type <id>)"
if [ "${item_type}" = 'text' ]; then
  cliphist decode | wl-copy --type text/plain
else
  cliphist decode | wl-copy
fi

Although the issue is triggered by the MIME type inference in wl-copy, cliphist has access to the original clipboard data type when storing clipboard history. Preserving this information avoids relying on heuristic MIME type detection during restoration and allows consumers such as wl-copy to use the original type information directly.

[sentriz]

hi @xeorain thank you for the change. though i think this is a breaking change for peoples current databases

my plan is to add a sidecar bucket that holds metadata about entries such as the time it was inserted, mime type, etc. this helps with #100 and #167

[xeorain]

Thanks, @sentriz, I totally understand your standpoint of avoiding breaking changes, although I think most of users may not keep their clipboard history permanently.

I will be looking forward to the sidecar bucket implementation, as it can also help improve the efficiency for cliphist list by querying the MIME type instead of repeatedly calling image.DecodeConfig() on each entry in a loop.