Enhance OpenVINO backend with view operations and new ops

[zhaixuejun1993]

This pull request adds support for the CONCAT, ARGSORT, and SOFTPLUS operations in the OpenVINO backend, and improves view op handling for several operators. It introduces new translation functions for these operations, updates operator tables and supported op lists, and refines how view ops are processed to improve compatibility and correctness.

New OpenVINO operator support:

• Added support for GGML_OP_CONCAT (concatenation) and GGML_OP_ARGSORT (argsort) in the OpenVINO backend, including new translation functions (translate_concat and translate_argsort), operator table entries, and support checks. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
• Added support for the GGML_UNARY_OP_SOFTPLUS unary operation, including the translation function and operator table entry. [1] [2] [3] [4] [5]

View op handling improvements:

• Updated translation functions for several operators (e.g., GET_ROWS, SILU, all 1-to-1 unary ops) to use the new process_view_input_new utility, ensuring correct handling of view ops as inputs. [1] [2] [3]
• In the backend comparison logic, added a special case to skip view op checks for OpenVINO, which does not handle view ops directly.
• Relaxed restrictions on view op inputs for unary ops in OpenVINO, now allowing them except for a small set of explicitly unsupported ops. [1] [2]

These changes expand the set of supported operations for OpenVINO and improve robustness and compatibility when working with view-based tensors.## Overview

Additional information

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure:

[wine99]

Can we avoid this? Hardcoding backend-specific checks for OpenVino into the GGML code isn't ideal

[zhaixuejun1993]

can not avoid, the VIEW op is handled in following node, which can be fused maybe, so can not compare, it has to be isolated.

[cavusmustafa]

Is it required for a model support or unit test currently?