Implement pretty printing for SelectOp, ClampOp, AfterAllOp types. Clean up type prints.

[GleasonK]

Pretty print for SelectOp based on vector display of arith.select: https://mlir.llvm.org/docs/Dialects/ArithmeticOps/#arithselect-mlirarithselectop

// Element-wise vector selection in arith:
%vx = arith.select %vcond, %vtrue, %vfalse : vector<42xi1>, vector<42xf32>

// StableHLO display:
%0 = stablehlo.select %arg0, %arg1, %arg1 : tensor<2x3xi1>, tensor<2x3xi32>

Note that if branch types do not match exactly, functional-type is used:

%1 = stablehlo.select %arg0, %arg2, %arg3 : (tensor<2x3xi1>, tensor<2x?xi32>, tensor<?x2xi32>) -> tensor<2x?xi32>

Now that SameOperandsAndResultType is merged into main, we can use it in other ops that may have the same operands and result types like ClampOp, or ops that must have matching types like AfterAllOp:

%0 = stablehlo.clamp %arg0, %arg0, %arg0 : tensor<4xf32>
%5 = stablehlo.after_all %arg1, %arg1 : !stablehlo.token
%6 = stablehlo.after_all : !stablehlo.token

Added print tests and invalid MLIR tests.

Additionally this change cleans up some type prints, removing parentheses around operands / including parens around inputs in type printing for consistency with the rest of the dialect's assembly:

%0 = stablehlo.cstr_reshapable %arg0, %arg1 : (index, tensor<3xi32>) -> !shape.witness
%0 = stablehlo.compute_reshape_shape %arg0, %arg1 : (index, tensor<2xi32>) -> tensor<2xi32>
%0 = stablehlo.complex %arg0, %arg0 : (tensor<4xf32>, tensor<4xf32>) -> tensor<4xcomplex<f32>>

[burmako]

Oof this is unfortunate. Let me take a closer look at this during the next pass over this PR. I'll submit my review for now because there's already plenty of comments to address.

[burmako]

I've been staring at how this function creates a temporary vector of pointers and realized that reuse is probably overrated in this case. Then I rewrote this function without leveraging parseSameOperandsAndResultTypeImpl, and I think I like the result better:

ParseResult parseVariadicSameOperandsAndResultType(
    OpAsmParser& parser,
    SmallVectorImpl<OpAsmParser::UnresolvedOperand>& operands,
    SmallVectorImpl<Type>& opTypes, Type& result) {
  llvm::SMLoc loc = parser.getCurrentLocation();

  Type type;
  if (parser.parseType(type)) {
    return failure();
  }

  // Handle if function type, all operand types did not match result type.
  if (auto fnType = type.dyn_cast<FunctionType>()) {
    if (fnType.getResults().size() != 1) {
      return parser.emitError(loc, "expected single output");
    }
    llvm::append_range(opTypes, fnType.getInputs());
    result = fnType.getResults()[0];
    return success();
  }

  // Handle bare types. ` : type` indicating all input/output types match.
  opTypes.append(operands.size(), type);
  result = type;
  return success();
}

Yes, there is some duplication with parseSameOperandsAndResultTypeImpl (more precisely, the parseType and dyn_cast and fnType.getResults().size() != 1 parts), but I think this version of code is easier to understand. What's yout take on this?

[GleasonK]

Hmm.. So the real advantage of reuse in printer/parser code in my opinion is the parity:

let x = printSameOperandsAndResultTypeImpl(input)
let y = parseSameOperandsAndResultTypeImpl(x)
assert(y == input)

I feel like there is extra gravity to code duplication in printer/parser code. Duplicating this code adds the overhead of "if we change anything about the printer code, we need to update the parser code in two places." I'll keep thinking on how to improve this.

[burmako]

Looks like I clicked "Comment" in my previous review, instead of "Request changes".