Fixed crash when adding to C cache a Composite Op created before adding / modifying some config options

- Added some doc about the identity, commutative and associative fields
- Fixed crash in filter function when using NaN values

sger accumulates into an output buffer, so if a c-continuous output
memory buffer was used several times, the result was incorrect.

If scan receives memory in the output storage map it uses it. Now if you run
truncated BPTT, you do not loop over the entire sequence, and you should
return 0 for all the entries you don not visit. I used to assume that the
data I allocate does that ( because I used to allocate it using zeros), but
now if data is provided I did not check if those values are actually 0s.

Before, scan used to add another layer of abstraction between constants and
the inner function, so even if you would give as a non sequence a constant
the inner function will treat it like a normal theano variable stopping
certain optimizations to happen.

It was added by James in f062502a097c but he does not remember why it was
there. It looks like it was never used.

This parameter has been made useless since cbb136aad3a8 (July 2009), so it
seems likely we do not need it.

The previous mechanism could take over a minute with a big cache.
It did two checks:
    1. (expensive check) Compare pair-wise all keys loaded, and find those
       that are equal even though they have a different hash.
    2. (cheap one) Ensure that unpickling a pickled key yields a key that is
       equal to the original one.
Those checks are now replaced by a new check that is performed each time a new
key is saved in the cache. We reload the pickled KeyData object and ensure
that it contains exactly one unpickled key equal to the key originally saved.
It is obvious it will catch errors that would have been caught by check #2.
It will also catch errors that would have been caught by check #1 because if
two keys are equal, they must yield a similar module hash, and thus they will
be stored in the same KeyData object: if they have a different key hash, they
will both appear in the 'keys' set of the KeyData object, and thus the new
check will complain there is more than one key found to be equal to the one we
just saved.

NB: Also removed a couple TODOs now that I understand better why some code was
written that way.