Add more padding variations: cycle, replicate and mirror

[laszlokorte]

Until now only constante padding (Nx.pad/3) and reflection padding Nx.reflect/2 are supported by Nx.

This pull request adds Nx.cycle/2 for cyclic padding, Nx.replicate/2 for using the outmost value along each axis as pad value and Nx.mirror/2 which behaves similar to Nx.reflect/2 but does repeat the edge values.

I did already propose especially the cyclic padding in #1708

[polvalente]

Very nice PR!

Let's also add some tests (maybe in nx_test.exs?) that stress test some of the edge cases, such as negative padding config (Nx.pad does slicing in the case of negative padding, maybe these need to do the same? Do we have Numpy references for these?)

[polvalente]

Suggested change

	left = Nx.subtract(n - 1, Nx.iota({n}))
	right = Nx.iota({n})
	right = Nx.iota({n})
	left = Nx.subtract(n - 1, right)

we might need to do something a bit more complicated here, in that iota being a creation function might need to receive the backend opts extracted from the input argument

[polvalente]

@josevalim do you think this is something we should be concerned about?

[polvalente]

@josevalim WDYT we add type: :padding instead and move some of the previous funs there as well?

[josevalim]

Sorry, I originally thought we were adding only a single function, but after seeing we need multiple and looking at the implementation (thank you!), I think we should go ahead and pass the mode as second argument to pad, as done for numpy: https://numpy.org/doc/stable/reference/generated/numpy.pad.html (using same names too). Especially because the padding_config is still a required argument. In this scenario, we would deprecate Nx.reflect/2.

For example: Nx.pad(tensor, :reflect, padding_config), Nx.pad(tensor, :symmetric, padding_config). Plus numpy has a few other modes we may want to add, so this will avoid adding 7-8 different functions.

[laszlokorte]

I agree that unifying with pad/3 would be much cleaner.

[laszlokorte]

I have update the code to unify the 4 padding styles into the pad/3 function. currently the padding_config for pad/3 expected {left, right, interior} for the constant padding but the reflect/2 function - that I based the other padding styles on - expects {left, right}, not supporting interior padding.

I am not sure what makes most sense API-wise. Just document that the padding_config format differs depending on padding type or come up with some sensible value for interior values (just constant 0?) for the other padding types.

[josevalim]

Ah, if they have different padding_config then it may make sense to give the function a different name. Overall, I think this approach is better, we just need to figure out the name.

[laszlokorte]

I agree that making the padding_config structure vary by padding type is confusing but a unifying approach could be:
For constant padding allow {left, right, interior} (as before) as well as {left, right} (new) defaulting {left, right, 0}
and for the other padding types also allow both {left, right, interior \ 0} and {left, right} but just using 0 as constant interior value.

Alternative names could be pad_outside or pad_around but at a first glance I do not like either.