Fix formula of Gabor kernel

[devmotion]

There's an inconsistency in the mathematical definition and the implementation that I missed. The Gabor kernel is implemented as a product of a Gaussian and a cosine kernel, both possibly with a (possibly element-wise) lengthscale transformation of the inputs. The formula should reflect this now correctly.

That being said, the Gabor kernel implementation is definitely one of the stranger implementations. It still feels weird to wrap the product in its own struct, a function gabor would be sufficient it seems. I am also wondering if one should drop one of the lengthscale transformations and instead define the kernel with ell = 1 (or p = 1). One would have to apply a separate input transformation to set this parameter, as for other kernels currently, and scale the other parameter accordingly.

[devmotion]

Maybe one could define something like

function gabor_kernel(; sqexponential_transform=IdentityTransform(), cosine_transform=IdentityTransform())
    return transform(SqExponentialKernel(), sqexponential_transform) * transform(CosineKernel(), cosine_transform)
end

instead of the current implementation. I don't think it's helpful to remove one of the transformations, as speculated above, since it would make it more complicated (and sometimes impossible) to recover the original inputs for one kernel if one modifies the inputs for the other one with an additional transformation of the original inputs.

[devmotion]

BTW it seems it would be useful to define

transform(k::Kernel, ::IdentityTransform) = k

[devmotion]

@willtebbutt @theogf What's your opinion? Should we deprecate Gabor and add the suggestions (gabor and transform(, ::IdentityTransform)) above?

[theogf]

I definitely think we should deprecate Gabor. Sorry for the duplicate in the issue, I completely forgot about this PR...

I would also be positive for transform(, ::IdentityTransform)

[theogf]

For gabor instead of the product can't we use the spectral_mixture_kernel instead? Since it's a special case?

[devmotion]

It is a special case but I don't think we want to just call the current implementation of spectral_mixture_kernel. It would lead to an unnecessarily complicated kernel since it creates a KernelSum of multiple weighted KernelProducts instead of just a simple unweighted KernelProduct and requires to specify a vector of these weights. I also don't think there would be gained much implementationwise since the gabor (or maybe gaborkernel?) implementation would be only 3 lines of code anyway.

[devmotion]

Can someone approve this PR and then I'll open a new PR with the deprecations and suggestions above when it is merged? I think this would be a bit cleaner than adding more changes here.