Add intoAlways overload that accepts a list of diffusers

[Frugghi]

A common pattern is to create a Diffuser that is a combination of several diffusers that map individual properties of the model:

let diffuser: Diffuser<Model> = .intoAll([
    .map(\.propertyOne, .into { /* do something with propertyOne */ },
    .map(\.propertyTwo, .into { /* do something with propertyTwo */ }
])

This works fine except that it forces you to make the model Equatable because intoAll requires the object to be Equatable. When using this pattern, you don't care about the model being Equatable but only about the individual properties being Equatable, in fact the entire object will be cached by intoAll and then each property will be cached by into.

To avoid this unnecessary conformance to Equatable, this PR introduces a variant of intoAlways that accepts a list of diffusers and always run them making the previous example:

let diffuser: Diffuser<Model> = .intoAlways([
    .map(\.propertyOne, .into { /* do something with propertyOne */ },
    .map(\.propertyTwo, .into { /* do something with propertyTwo */ }
])

Since the individual properties are still Equatable as required by .into, the two examples above are pretty much equivalent.

[zvonicek]

Is this sentence still relevant in those two new variants of intoAlways?

[zvonicek]

Also, perhaps you could document briefly the intended use case of intoAlways for non-Equatable models with Equatable members.

[Frugghi]

Updated! I think that sentence would still apply in this case but it's not really that clear so I replaced it to point out about the existence of intoAll instead.

[zvonicek]

One trade-off of this PR is that when the base model is Equatable, there are now two ways of expressing the identical logic, by using .intoAlways or .intoAll. Ideally, I would like the library to be more opinionated and prevent such a state, but I understand that there are limited ways of doing so at the moment without causing a BC break.

I, on the other hand, quite like the .intoAlways solution for dealing with non-Equatable base models, which seems like an elegant way to incorporate this much needed capability into the library.

So I think that we can go ahead with merging this one!

[zvonicek]

cc @togi in case you have any thoughts on this before we merge it

[Frugghi]

One trade-off of this PR is that when the base model is Equatable, there are now two ways of expressing the identical logic, by using .intoAlways or .intoAll.

I get the point but I don't think it's any different from .intoAlways vs .into. They express identical logic only if you combine them with something like map + into like in the examples I provided.