Auto-select conv2d implementation based on kernel/input size

[rmatif]

Since #14316, #14388, and #14403 will add a new conv2d direct op, I'm considering if we can add a mechanism that automatically chooses the best method during graph construction, it could decide between the direct ggml_conv_2d op and the indirect im2col+gemm method based on kernel or input size (determined heuristically with hardcoded thresholds). This would build the most performant path. Or maybe a wrapper by implementing a new op like GGML_OP_CONV_2D_AUTO that will call either direct or direct op based on input/kernel, still not sure le on how to do it.

@slaren I'd like to know your thoughts on this. It's a standard practice in other frameworks, but I'm not sure if it's desirable here

[slaren]

I would say the goal is to make the _direct functions standard, and backends are free to implement it in any way they want, including using im2col as it is done now. Once most backends have implemented the _direct ops, we can rename them and remove the old versions, or keep them under a _im2col suffix if they still have some use.

[rmatif]

I'm not sure that _direct would be faster across all backends and in all scenarios. However, I think it might be better to handle this on the backend side rather than at the high level, since developers may choose different conv2d function depending on the data and/or hardware. I'm considering giving Winograd-based conv2d a shot, but I know in advance that it won't be faster on CUDA or for certain kernel sizes, which is why I thought of implementing a conv2d wrapper. Thanks for the answer!