BUG: `np.einsum` accepts some subscripts only when optimize=True

It seems that the acceptable syntax of np.einsum subscripts are different when optimize option is set or not.

>>> import numpy as np

>>> x = np.ones((2, 2, 2))

>>> np.einsum('...->', x, optimize=True)
8.0

>>> np.einsum('...->', x, optimize=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/kenichi/.pyenv/versions/local-3.6.3/lib/python3.6/site-packages/numpy/core/einsumfunc.py", line 948, in einsum
    return c_einsum(*operands, **kwargs)
ValueError: output had too few broadcast dimensions

>>> np.einsum('i...j->ij', x, optimize=True)
array([[ 2.,  2.],
       [ 2.,  2.]])

>>> np.einsum('i...j->ij', x, optimize=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/kenichi/.pyenv/versions/local-3.6.3/lib/python3.6/site-packages/numpy/core/einsumfunc.py", line 948, in einsum
    return c_einsum(*operands, **kwargs)
ValueError: output has more dimensions than subscripts given in einstein sum, but no '...' ellipsis provided to broadcast the extra dimensions.

[jaimefrio]

I have started looking into einsum’s parsing, see #11095. If that gets merged I’ll look into making the parsing a standalone function, and adding a Python wrapper so that ‘einsum_path’ can call it and we can get rid of the duplicate parsers.

[toslunar]

Found by @asi1024:

>>> numpy.einsum('a- >a', numpy.array([3,4]), optimize=True)
array([3, 4])
>>> numpy.einsum('. ..->...', numpy.array([3,4]), optimize=True)
array([3, 4])