[WebGPU EP] Add EINSUM implementation

[feich-ms]

Description

This PR added the native implementation of einsum operator, based and expanded on existing einsum.ts. All the test cases in einsum_test.cc have been passed.

The equation attribute value of einsum op is a string which consists of left hand side (LHS) and optionally right hand side (RHS) separated by '->'. Ex.

• "ij->ji" matrix transpose
• "ii->i" diagonal elements of a square matrix
• "ij->" sum over all elements of a matrix
• "ij,jk->ik" explicit matrix multiplication
• "ij,jk" implicit matrix multiplication
• "ij,jk->" matrix multiplication and sum over all elements
• "ij,jk,kl->il" three matrix multiplication
• "...ij,...jk->...ik" batched matmul with broadcasting
• ",...i->...i" matrix element multiplication with one scalar
• "abc,cd->abc" keep the original abc matrix shape but matmul and sum over along d

LHS consists of a sequence of terms separated by commas. Each term corresponds to an input variable.
Each symbol corresponds to a dimension in the input variable. The symbol can be either a letter, 'a' to 'z' or 'A' to
'Z' or '...' to represent arbitrary dimensions or empty to represent a scalar.

Empty RHS are handleed differently for implicit vs explicit modes.

• Implicit mode - arrow is not in the equation where the equation "ij,jk" equals to "ij,jk->ik" which is actually a matrix multiplication.
• Explicit mode - arrow is in the equation where the equation "ij,jk->" contains two steps, first step is a matrix multiplication just like the implicit mode, and the second step is to sum up the matrix produced by the first step to a scalar.

For all the test cases, pls refer to einsum_test.cc

[feich-ms]

@satyajandhyala @xiaofeihan1 @qjia7 @guschmue @fs-eire, pls help to reiview, thanks.

[fs-eire]

The equation_ is an attribute, which means it is constant and will not change for each calls to Einsum::ComputeInternal in this context. Is there a way to move some preparing steps into the kernel constructor so that we don't have to do this multiple times?

[feich-ms]

Thanks for the suggestion. I dived deep into the logic and looks like it's not easy to move the eqaution parsing logic into the kernel constructor, the reason is that the equation parsing heavily depends on the input shapes, especially depends on the input dimensions to handle cases with "..." in the equation, like ...ij,...jk->...ik. When parsing the equation from left to right, we need to know the input dimensions to fill up the ellipsis dimensions. Another case that heaily depends on inputs is something like "ij,jk" which need to fill up the output shape implicitly. What we can move into kernel constructor is only the term string parsing which is low cost and then we still loop the parsed term strings and process term in the ComputeInternal function, so I think it makes little sense to make these changes given it brings little improvements. What do you think?