we should have as initial value for some parameter 0, unless it
is a random state, case in which is not differentiable and should
be None

Issue : scan used to compute something, that I thought was the R-op with
respect to shared variables with updates of the inner function. After
more reflection, I think those numbers I'm computing have no meaning ..

Unless the user asks explicitly for the R_op with respect to some value
that is a shared variable, this would not affect anything (just some extra
computations). The reason I removed them is not only the possible
meaningless of these numbers, but also the fact that R_op methods are not
defined for random number sampling function, which would appear as
shared variable. So you would get that you can not compute the R-op because
some function is not defined for that op, even though that is only to
compute some values you don't care and which might not have any meaning.

I have no idea exactly how to test this, since is not a bug per-se is more
of a semanting error in my understanding of what the R-op is suppose to do.

in {zeros,ones}_like, don't insert fill for scalar.

Fix tests error when scipy is not there

Improved testing of preallocated outputs in DebugMode

Fix a Scan test. It is normal both scan got merged.

This  make  the  graph  before  compilation  and  when  compiled  with
FAST_COMPILE   more    readable.   This   was    optimized   away   to
local_fill_to_alloc, but if  we enable it in fast_compile,  it also do
more optimisation that make the  graph not readable without enabling even
more optimization in fast_compile.s

This reflects the fact that the C linker is not necessarily the problem,
and that this exception is also raised when different calls to the same
thunk (for instance, with different preallocated outputs) give different
results.

Also, do not return a preallocated map it if is empty,
and fill "previous" storage with default value.

Otherwise, we have to allocate 2**ndims times the amount of memory,
and 2**4 seems enough.

Also, strides 1 and -1 will not be tested independently on the
dimensions above 4, their strides will always be all 1 or all -1.

The += syntax is not implemented for dims > 5.
Also actually use a tensor of wrong size in "wrong_size" mode.

If an input is viewed, and the corresponding output is destroyed,
then it destroys the input.
There would be ways to be more precise, but at least this is correct.

Fix test

Fix scan debugmode

Fix scan debugmode

destroy_map is not always defined for a scan op.

Fix tests

Looks ok to me.