Refactor received attachment view/open handling into modular rule-registry system

[yousefakbar]

Incoming attachment handlers are now just ordered rules. You can match by extension, content type, filename, size, disposition, message id, or arbitrary Lua logic; then open externally, render into a preview buffer, or run fully custom Lua handlers.

• Replace legacy received attachment open/view handlers with rule-based incoming attachment subsystem
• Add cache-backed extraction and structured incoming attachment objects
• Add default open/view rule registries for system openers and text previews
• Add user-friendly attachments.* shorthand config
• Add advanced attach.incoming.* patch (prepend, replace, append, disable) API
• Document breaking removal of open_handler / view_handler
• Add tests for incoming attachment modules and config behavior

Here is a sample configuration setup for overriding (prepend before the default rules) the calendar view rendering with khal or mutt-ics for viewing calendar invitations with a custom-set tool.

require('notmuch').setup({
  attachments = {
    view = {
      {
        name = 'khal-calendar', -- Any name for the rule
        match = { ext = 'ics' }, -- or { content_type = 'application/ics' },
        commands = { -- Try these commands in this order -- $path is the filename internally
          { 'khal', 'printics', '$path' },
          { 'mutt-ics', '$path' },
        },
        filetype = 'markdown', -- Set the filetype of the rendered output
        fallback = 'Install mutt-ics to preview ics files.', -- Fallback incase `commands` failed.
      },
    },
  },
})