New expression blocks

[vincentsarago]

closes #477

proposed by @geospatial-jeff in slack: use ; instead of , to support multi-blocks expression.

To avoid breaking change/major release, we will still support , delimited blocks, so users who wants to use , in expression HAVE TO put a ; at the end of the expression

expression="where((b1==1) | (b1 > 0.5),1,0)" -> ["where((b1==1) | (b1 > 0.5)" , "1" ,"0)"]  # Not OK

expression="where((b1==1) | (b1 > 0.5),1,0);" -> ["where((b1==1) | (b1 > 0.5),1,0)"]  # OK

I understand this is not optimal but IMO it's the better solution (to my knowledge) to avoid using complex regex or hacky solution. But I'm 👂

Note:
https://numexpr.readthedocs.io/projects/NumExpr3/en/latest/user_guide.html#supported-functions
where(bool, number1, number2), arctan2(float1, float2), {real,imag}(complex), complex(float, float), sum(number, axis=None) and prod(number, axis=None) are the NumExpr function which could need a ,.

[iferencik]

@vincentsarago thank you for your super quick fix. I plan to use these features to experiment with doing some raster algebra
on the fly. After this merge do I need to update rio-tiler from github?

[vincentsarago]

I'll try to have a release today if @geospatial-jeff and @kylebarron help me 😄

as mentioned in ☝️ to be able to use complex expression you'll need to add ; at the end of the expression.

[geospatial-jeff]

I can't think of a better way to do this that isn't breaking. A little uncomfortable that we aren't fixing the underlying problem (relying on character in numexpr to split expressions), but I understand the desire to not cut a new major version just for this and I think the deprecation warning should be enough for now.

This should work until 4.0 comes around!