Issue title: bug in cse when applying it to a list of long expressions?
 Issue body: @isuruf 
looking at #1338  it seems that this issue popped up already a while ago, but 
since i am currently using the latest dev-version  (116.69.203.115.g398a3f3) i think 
this fix is already implemented in my version.

however, while trying to implement the new symengine-cse functionality 
(whose existence i greatly appreciate) i unfortunately found that there seems to be 
some problems remaining when applying cse to lists of large expressions.

since i can not directly isolate the problem, i wrote the following minimal example
to show what's happening:

txt-file with a list of trigonometric polynomials: [asdf.txt](https://github.com/symengine/symengine/files/1414175/asdf.txt)

```python
import numpy as np
from symengine import var, cse, sympify, Lambdify
from sympy import cse as sympy_cse

# read list of functions
with open('PATH TO asdf.txt FILE', 'r') as text_file:
        asdf = text_file.read().splitlines()

# initialize symbols used in asdf.txt
theta_0 = var('theta_0')
# convert asdf to symengine expressions
funlist = sympify(asdf)
# generate a function to directly evaluate the expressions provided in asdf.txt
funeval = Lambdify(theta_0, funlist)

# use symengine to perform cse
repl_symeng, fun_symeng = cse(funlist)

# use sympy to perform cse
repl_sympy, fun_sympy = sympy_cse(funlist)


# undo symengine cse
newfun_symeng = fun_symeng
for n, _ in enumerate(fun_symeng):
    for i in range(len(repl_symeng)):
        newfun_symeng[n] = newfun_symeng[n].xreplace(dict(repl_symeng)) 
# generate a function to check for consistency before and after cse
symeng_funeval = Lambdify(theta_0, newfun_symeng)

# undo sympy cse
newfun_sympy = fun_sympy
for n, _ in enumerate(fun_sympy):
    for i in range(len(repl_sympy)):
        newfun_sympy[n] = newfun_sympy[n].xreplace(dict(repl_sympy)) 
# generate a function to check for consistency before and after cse
sympy_funeval = Lambdify(theta_0, newfun_sympy)


# calculate the difference before and after cse
# (supposed to be 0.0)
diff = [(funeval(.5) - sympy_funeval(.5)),
        (funeval(.5) - symeng_funeval(.5))
        ]

# print the differences
for i, j in np.array(diff).T:
    print('sympy:', i, '   symeng:', j)
```

alternatively you can execute this to see the problem symbolically...

```python
from sympy import simplify

test = [0]*len(newfun_symeng)
for i, nf in enumerate(newfun_symeng):
    test[i] = simplify(nf - funlist[i])

```
**cse of individual list elements:**
...since i already digged a little bit into the problem:
applying cse to each expression individually yields reasonable numerical errors
(sympy still succeeds here and gives exactly 0.0 which i also don't fully get...
is this due to the *c <-> python* conversion of symengine?)

```python
for N in range(len(funlist)): 
    # generate a function to directly evaluate the N'th expression
    funeval = Lambdify(theta_0, funlist[N])
    # use symengine to perform cse of the N'th expression
    repl_symeng, fun_symeng = cse([funlist[N]])
    
    # undo symengine cse
    newfun_symeng = fun_symeng
    for n, _ in enumerate(fun_symeng):
        for i in range(len(repl_symeng)):
            newfun_symeng[n] = newfun_symeng[n].xreplace(dict(repl_symeng)) 
    # generate a function to check for consistency before and after cse
    symeng_funeval = Lambdify(theta_0, newfun_symeng)
    
    print((funeval(.5) - symeng_funeval(.5)))

```






 Comments: 
 Comment 0: `116.69.203.115.g398a3f3` is 23 days old and the PR was merged 21 days ago.
 Comment 1: thanks for the quick reply... that is very good to hear!
i updated symengine yesterday via ` conda install -c symengine/label/dev symengine `
what would be the correct way to get a version that includes #1338?

 Comment 2: @raphaelquast, send a PR like https://github.com/symengine/python-symengine-feedstock/pull/3/files
 Comment 3: @raphaelquast, can you check whether this is fixed or not?
 Comment 4: @iusuruf i did some tests and i can confirm that the behavior of Lambdify and cse is now as expected.
Thank you very much for this!

However, the behaviour of LambdifyCSE is still not as expected as can also be seen by running the code in my last comment on symengine/symengine.py#174

There might be an error concerning the newly introduced "order"-parameter within `LambdifyCSE`
wich can directly be seen by using higher-dimensional input arguments in the above tests as:


txt-file with a list of trigonometric polynomials: [asdf.txt](https://github.com/symengine/symengine/files/1414175/asdf.txt)
```python

from symengine import var, sympify, Lambdify, LambdifyCSE

# read list of functions
with open('PATH TO asdf.txt FILE', 'r') as text_file:
        asdf = text_file.read().splitlines()

# initialize symbols used in asdf.txt
theta_0 = var('theta_0')
# convert asdf to symengine expressions
funlist = sympify(asdf)
# generate a function to directly evaluate the expressions provided in asdf.txt
funeval = Lambdify(theta_0, funlist)

funeval = Lambdify(theta_0, funlist, order='F')
funeval([.4, .5]) 
# yealds correct result

funeval_CSE = LambdifyCSE(theta_0, funlist, order='F')
funeval_CSE([.4, .5]) 
# ValueError: all the input array dimensions except for the concatenation axis must match exactly


funeval_CSE = LambdifyCSE(theta_0, funlist, order='C')
funeval_CSE([.4, .5]).T
# yields same result as funeval([.4, .5]) 

```


Furthermore (in a different piece of code) even if i provide `order = 'F'` as an argument
to `LambdifyCSE`, I get the error:  `ValueError: C order implies .....`


I think this issue can be closed since the issue of LambdifyCSE certainly is not an issue of the
cse functionality used (which is still sympy.cse from the docstring) as the numerical values are correct
and just the shape of the input- and output- arrays is different.

Should I add this comment to symengine/symengine.py#174 where it would fit better to the discussion? 

{'source': 'GithubIssues', 'repo_name_with_owner': 'symengine/symengine', 'issue_id': 268358280, 'repo_stars': 860.0}