Documentation improvements (inc. lengthscale explanation) and Matern12Kernel alias

[st--]

Just some minor edits for clarity and typos while going through the docs, and adds Matern12Kernel as alias for ExponentialKernel (in line with the explicitly defined Matern32Kernel and Matern52Kernel). Incorporates the lengthscales explanation from #212.

[theogf]

It looks good, I don't see any issue. You don't necessarily have to correct spacing in latex since it is going to be ignored anyway.

[devmotion]

Errors are caused by FluxML/Zygote.jl#873.

[st--]

Should we explicitly mention using first(Functors.functor(k)) as an example (see #212 (comment))?

[willtebbutt]

This seems like a good idea to me -- a brief sentence would probably suffice. @devmotion @theogf any thoughts?

[theogf]

So I checked and this is not completely true unfortunately:

using Functors
k = 2.5 * transform(SqExponentialKernel(), 2.0)
first(functor(k)) == ((kernel = Squared Exponential Kernel
	- Scale Transform (s = 2.0), σ² = [2.5]))

[st--]

@theogf @willtebbutt @devmotion I've addressed all review comments as far as I can tell, though I've got a few questions left open. Other than that, what else is missing for you to approve this PR?

[willtebbutt]

Thanks for the contribution @st-- . I'm happy for this to be merged as-is, but I'm also happy to discuss / address the following in this PR or another.

I'm concerned is that we're duplicating documentation a bit at the minute by having both docstrings and having the entire Kernels section written out manually. This creates an opportunity for the docs to decouple from the docstrings and increases the maintenance burden. I wonder whether it would make sense, therefore, to consolidate this documentation -- if we were to move the concise mathematical description of the kernels from the docs to the docstrings, and just move /duplicate bits of the API section in the Kernel Functions section we could get the best of both worlds?

If people feel that this is out of scope for this PR, I'll open a separate issue to discuss.

[st--]

I've opened #217 and #218 to discuss/address some of the points that were brought up by this PR. I'd be in favour of keeping PRs small (this one went from just fixing a few typos to taking several days already 😅 ), and split out these larger discussion/change points.

Two open questions:

1. Documentation improvements (inc. lengthscale explanation) and Matern12Kernel alias #213 (comment): Is that a good(-enough) way of incorporating TensorProduct for now? (And/)Or should we open another issue for that?
2. Documentation improvements (inc. lengthscale explanation) and Matern12Kernel alias #213 (comment): Should we explicitly mention using first(Functors.functor(k)) as an example (see #212 (comment))?

[devmotion]

I'm fine with the PR, I think further improvements (in particular, updating the docstrings and using them on the webpage) should be done in other PRs. I also think 1 and 2 should not be addressed in this PR - I think it is better to not mention TensorProduct there for now instead of forcing it into this section which only mentions sums and products, and in my opinion most users won't call or look into Functors.functor, so we might not need an example there (currently).

[willtebbutt]

Looks like I forgot to hit approve.

[devmotion]

Ah I also forgot it 😄

[st--]

Yay! Happy to contribute my first PR on here. I've added points 1. and 2. to #221 to keep track of them.