Add option to filter on transformed candidates (e.g. with ivy-rich) for a given command

[cjauvin]

As an happy user of https://github.com/Yevgnen/ivy-rich, I've been looking for a way to augment the filtering of my beloved ivy-switch-buffer (aka. C-x b) function with the extra columns. In fact this issue has been raised a few times, to my knowledge:

#2847
Yevgnen/ivy-rich#28
Yevgnen/ivy-rich#60
Yevgnen/ivy-rich#89

After recognizing the inherent performance problem with a general solution, I came up with this solution, which allows to easily turn on the feature on a per command basis, at the price of an extra custom variable, and a simple modification to ivy--re-filter. For instance if you are already using ivy-rich and your ivy-rich-display-transformers-list is set, as mine, to:

'(ivy-switch-buffer
  (:columns
   ((ivy-switch-buffer-transformer (:width 0.15))
    (ivy-rich-switch-buffer-indicators (:width 4 :face error :align right))
    (ivy-rich-switch-buffer-project (:width 0.075 :face success))
    (ivy-rich-switch-buffer-path (:width 0.1))
    (ivy-rich-switch-buffer-major-mode (:width 0.05 :face warning :align right)))
   :predicate
   (lambda (cand) (get-buffer cand))))

then doing:

(ivy-configure 'ivy-switch-buffer
  :should-filter-transformed-candidates-p t))

will allow you to filter your buffers by their project names and major modes, in addition to the file names, which in my case at least, is quite handy. You can turn off the feature by setting the same value to nil.

As mentioned earlier the problem with this approach is that if you try to use it with a version of counsel-M-x augmented with function descriptions, for instance, there will be a very noticeable performance cost, because there are simply too many candidates, and the transform function is quite expensive. I think my per-command solution is an acceptable compromise however, and works particularly well with ivy-switch-buffer (although I admit my particular style is not to have hundreds of open buffers at any time though). Moreover there might be a way to speed up things by using caching or async logic, but that is outside of the scope of this PR.