Adding non-mutating recur for the new chain interface.

[mkschleg]

This adds the necessary implementation details for recurrent networks for the new chain api (#5). Sorry for the noise with #6 , but there was an issue with some merge conflicts that I thought I would resolve outside of the PR.

The tests indicate that this might solve some of the tests for explicit gradients. The gradient for state_0 still seems broken (returns nothing).

How this is done was adapted from Lux.jl.

PR Checklist

• Tests are added
• Documentation, if applicable

[mkschleg]

Test error looks to be something up with Zygote on master.

[ToucheSir]

I might've missed this from the apply PR, but why does NM_Recur implement _apply instead of apply? My impression was that apply would be the user-facing API for new layers to overload.

[mkschleg]

There might have been some miscommunication on the previous apply api. I thought we wanted to separate the exported apply for chains and the internal _apply for layers. We should be able to unify though.

[ToucheSir]

That may have been my fault. My thought was to use apply wherever possible, so unification would be great.

[mkschleg]

I've (mostly) unified apply. There is an issue with ambiguity between the single timestep apply and the time series apply over a vector/generator. I solved this by making the tuple calls _apply in chain.jl and adding another method for Flux.Chain. I don't know how sustainable that is for applying to Flux at large, but I think it might be ok because most layers shouldn't need a custom apply.

For the tuples (i.e. the chain.layers) specific applies we should use _apply. As I don't think beyond use in Flux.Chain a tuple of layers has a well defined use case (i.e. that is why parallel, join, etc exist).