Update eltwise flatbuffer to include extra params, move eltwise composite to own files

[jnie-TT]

Related #1093

As we're bringing up more ops, having a single flatbuffer table that describes parameters for eltwise ops isn't sufficient to cover all cases. For example, unary composite ops like clamp could have 2 extra float parameters min and max. These ops are however still modelled as eltwise operations in ttnn, so we should model them as eltwise in runtime as well.

This PR introduces a new union type EltwiseOpParams, which is a collection of extra parameters required for specific eltwise ops. These extra params can later be extracted in runtime to input into the ttnn op. This will allow us to add eltwise ops that have extra parameters in the future.

For example, if we were to add a ClampOp as an EltwiseOp, we could create special params for it:

table ClampOpParams {
  min: float;
  max: float;
}

union EltwiseOpParams {
  ClampOpParams,
}

Then handle it in TTNNToFlatbuffer.cpp with something like:

::flatbuffers::Offset<::tt::target::ttnn::ClampOpParams>
createEltwiseOpParams(FlatbufferObjectCache &cache, ClampOp op) {
  auto min = op.getMin().convertToFloat();
  auto max = op.getMax().convertToFloat();
  return ::tt::target::ttnn::CreateClampOpParams(*cache.fbb, min, max);
}

template <typename EltwiseOp>
::flatbuffers::Offset<::tt::target::ttnn::EltwiseOp>
createEltwiseOp(FlatbufferObjectCache &cache, EltwiseOp op) {
  ...
  else if constexpr (std::is_same_v<EltwiseOp, ClampOp>) {
    type = ::tt::target::ttnn::EltwiseOpType::Clamp;
    paramsType = ::tt::target::ttnn::EltwiseOpParams::ClampOpParams;
    params = createEltwiseOpParams(cache, op).Union();
  }

Then in runtime extract the required params.

This PR also moves unary/binary composite ops to their own files to match the implementation of ttnn and to reduce the size of unary.cpp and binary.cpp (especially as we add more composite ops).

FYI @mmanzoorTT

[nsmithtt]

What do we mean when we say "Composite" op in our runtime?

[jnie-TT]

It reflects the scheme of ttnn (in src/tt-metal/ttnn/cpp/ttnn/operations/eltwise/unary/unary_composite.hpp). They have a concept of unaryCompositeOp that has a different execution function signature than ordinary unary ops (same for binary_composite). Alot of these ops have extra parameters aside from the input tensor like min/max for clamp.

[nsmithtt]

I see ok makes sense.

[nsmithtt]

We should guard this underneath a workaround.

[jnie-TT]

Sounds good, FYI @uazizTT I think you added this, is this still required in runtime? Are there plans to do this in the compiler?

[jnie-TT]

Created issue #1124

[uazizTT]

Sounds good, FYI @uazizTT I think you added this, is this still required in runtime? Are there plans to do this in the compiler?

We don't intend to fix it in the compiler as it should be fixed in tt-metal, this is the reported issue in tt-metal to track it. tenstorrent/tt-metal#13566

Once tt-metal fixes it on their end, this workaround can be removed, but until then it can be guarded as a workaround in runtime.

[kmabeeTT]

lgtm