Einsum output order

[dgasmith]

I was pinged about an issue in the einsum optimization implementation that we are not careful enough in correctly replicating the order restrictions of c_einsum. See the issue and PR. This is a reminder that it needs to be patched here as well.

[dgasmith]

This turns out to be fairly messy since only the NumPy backend allows this kind of control. We have two options:

1. Note that dtype/order/casting is only valid for NumPy and implement them with if backend == 'numpy'.
2. Remove these kwargs from the docstring and replace them with backend_kwargs to indicate that these are simply passed to the backend to be evaluated on a per-contraction basis. We can indicate that this doesn't always do what you expect since the order flag for A type might give you a strange order back out since it depends on the order of the contraction.

I'm a bit in favor of 2) as we are continuously pushing towards being backend agnostic and I suspect these kwargs are not being relied upon. The lack of order in NumPy for example was caught only after 2.5 years while any bug or regressions in einsum(optimize=True) are caught before a release by multiple parties which run CI over alpha/beta NumPy releases.

[jcmgray]

I would also be in favour of the simplification i.e. 2. I guess the question is to what functions do the backend_kwargs get passed to? Just the last function call? An extra final call like einsum('abc->abc', x, **backend_kwargs)?