fix AdamW and improve decays docs

[CarloLucibello]

There is great disorder under the sky with optimizers. Since in chaining optimizers

opt = Optimizer(opt1, opt2)

the order generally matters (a lot!) we have to be very careful in documenting how to use decays. In fact, we were giving completely wrong indirections for InvDecays and ExpDecays. The correct ordering for standard use is

Optimizer(WeightDecay(), ADAM())   # equivalent to L2 regularization
Optimizer(ADAM(), InvDecay())   # learning rate scheduling
Optimizer(ADAM(), ExpDecay())   # learning rate scheduling

Different orderings are to be typically considered as bugs in user code.

This PR fixes examples and tries to clarify documentation in this regard.

Also fixes AdamW, which was doing something totally wrong due to the aforementioned confusion.
(see https://towardsdatascience.com/why-adamw-matters-736223f31b5d for how AdamW works).

Related in model-zoo: FluxML/model-zoo#303 and FluxML/model-zoo#304

[ToucheSir]

LGTM. I think this is further evidence that scheduling should be distinct from the optimizer interface ;)

[CarloLucibello]

@DhairyaLGandhi fixed the typos, need another approval

[DhairyaLGandhi]

bors r+

[bors]

Build succeeded:

• buildkite/flux-dot-jl

[darsnack]

Sorry for a missed review request (was traveling). Just want to agree with @ToucheSir that this is more evidence that scheduling policies and optimizers should not be forced to share the same interface even if it is technically possible.