Add support for visiting op classes

[jasilvanus]

Op classes are sets of ops, providing a common base class in the op class hierarchy,
which can be used to group sets of ops with a common property.

Before this patch, op class only support isa<> checks, but not visiting.

This was because visiting relies on OpDescription::get<OpT>, which is only supported
for concrete ops, but not op classes.

This patch changes that by introducing a new OpDescription::getAll<OpT> template
which returns an ArrayRef of OpDescriptions. The existing get<OpT> template
is implemented in terms of the new getAll template.

Visitor code is changed to use getAll instead, and handle non-trivial array refs
(representing op classes) accordingly, using the already existing mechanism for op sets.

I wondered whether it would be better to remove the existing get method and migrate everything to the new getAll method (and renaming it back to get). However, that would require to add support for op classes in all places that rely on OpDescriptions and get, which is more than just visitors. Thus I chose to add a new method for this.

Also, we could instead provide a generic implementation of get in terms of getAll, because all implementations of get are the same: They return getAll()[0]. However, that would also add such methods for op classes, which we don't want. We could assert that the length is one, but that turns a link-time error into a debug-only assertion failure, which is strictly worse. Maybe we could add some more traits that allow to detect op classes, but I didn't want to complicate things further.

[Flakebi]

Thanks, the comment reads good now.

There is an ArrayRef constructor that takes a single element: https://llvm.org/doxygen/classllvm_1_1ArrayRef.html#a7297c362c4fd96749704f50f1212b823

And a couple more std::array<*, 1> in the code

[Flakebi]

Thanks, that’s a nice diff!