Avoid doing bias-add by setting the bias value as the `outs` operand

@erman-gurses is already working on this.

Since May 27, 2022.

Looking at the IR generated from Torch-MLIR within IREE, after some fusion, I see these kind of patterns

```
%114 = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d2)>, affine_map<(d0, d1, d2) -> (d0, d1, d2)>], iterator_types = ["parallel", "parallel", "parallel"]} ins(%cst_18 : tensor<384xf32>) outs(%49 : tensor<1x128x384xf32>) {
^bb0(%arg1: f32, %arg2: f32):
linalg.yield %arg1 : f32
} -> tensor<1x128x384xf32>
%115 = linalg.batch_matmul ins(%113, %cst_182 : tensor<1x128x384xf32>, tensor<1x384x384xf32>) outs(%114 : tensor<1x128x384xf32>) -> tensor<1x128x384xf32>
```

If I am reading this correctly, this is a `batch_matmul` followed by bias add computation that is written as a broadcast of the bias into the output shape of the `batch_matmul` followed by the `batch_matmul`. Not sure this is the best way to represent the computation, it definitely trips up fusion at Linalg level. A better representation would be

```
%fill = linalg.fill ins(%cst_zero : f32) outs (%114 : tensor<1x128x384xf32>) -> tensor<1x128x384xf32>
%115 = linalg.batch_matmul ins(%113, %cst_182 : tensor<1x128x384xf32>, tensor<1x384x384xf32>) outs(%fill : tensor<1x128x384xf32>) -> tensor<1x128x384xf32>
%cst = linalg.generic {
indexing_maps = [affine_map<(d0, d1, d2) -> (d0, d1, d2)>, affine_map<(d0, d1, d2) -> (d2)>],
iterator_types = ["parallel", "parallel", "parallel"] {
^bb0(%b0 : f32, %b1 : f32, %b2 : f32):
%0 = arith.addf %b0, %b1 : f32
linalg.yield : f32
} -> tensor<1x128x384xf32>
```
At a very preliminary level this representation avoids the explicit broadcast of `%cst_182` (and FWIW the Tensorflow MLIR lowering of op + bias-add is done this way). I tend to think of this as a more canonical representation of the computation here.