Add clang-tidy checker to use free functions for casting

[ArtemySkrebkov]

Summary

Please add a short but exhaustive summary why you think your pull request is useful

• Add a custom checker for automatic replacement of member variants of the dyn_cast/cast/isa with the corresponding free functions. For example,

if (type.isa<Foo>() && type.isa<Bar>()) { ... } 
// will be replaced by
if (mlir::isa<Foo>(type) && mlir::isa<Bar>(type)) { ... } 

More examples in https://github.com/intel-innersource/applications.ai.vpu-accelerators.vpux-plugin/pull/16360

JIRA ticket

• E-71627

Related PR in NPU Compiler and/or OpenVINO repository with sub-module update

• PR-xxx

Other related tickets

List tickets for additional work, eg, something was found during review but you agreed to address it in another Jira

• E-xxxxx

[ArtemySkrebkov]

To be honest, I am not sure we need to merge this as this checker becomes useless once we move to LLVM19. So the checker can live in a branch.

However, there is no harm in merging as well. For the sake of history, for example 😺

So it is up to the maintainers of the repo to decide what to do with the PR.

[ggladilo]

To be honest, I am not sure we need to merge this as this checker becomes useless once we move to LLVM19. So the checker can live in a branch.

However, there is no harm in merging as well. For the sake of history, for example 😺

So it is up to the maintainers of the repo to decide what to do with the PR.

I wouldn't merge (at least as-is) since there's no tests and a few "FIXME" left
Anyway, I'm actually planning to enable custom clang-tidy checks support in npu compiler repo

[andrey-golubev]

To be honest, I am not sure we need to merge this as this checker becomes useless once we move to LLVM19. So the checker can live in a branch.

However, there is no harm in merging as well. For the sake of history, for example 😺

So it is up to the maintainers of the repo to decide what to do with the PR.

Given that we are about to migrate to LLVM19, do we still need this?

[ArtemySkrebkov]

I do no think so. Once we have every occurrence of cast methods removed, the PR can be closed. I keep it here just to have a way to fix something quickly.