[CK_TILE] Refactor ck_tile file structure

[aledudek]

Proposed changes

Please describe the motivation behind the pull request, whether it enables a new feature or fixes a bug. If there are associated pull requests or issues, please link them to the pull request.

Checklist

Please put an x into the boxes that apply. You can also fill these out after creating the PR. If you're not sure, please don't hesitate to ask.

• I have added tests relevant to the introduced functionality, and the unit tests are passing locally
• I have added the test to REGRESSION_TESTS list defined at the top of CMakeLists.txt in tests/CMakeLists.txt, IF the test takes more than 30 seconds to run.
• I have added inline documentation which enables the maintainers with understanding the motivation
• I have removed the stale documentation which is no longer relevant after this pull request
• (If this change is user-facing) I have added release notes which provide the end users with a brief summary of the improvement from this pull request
• I have run clang-format on all changed files
• Any dependent changes have been merged

Discussion

If this is a relatively large or complex change, feel free to start a discussion by explaining why you chose the solution you did and what alternatives you considered

[carlushuang]

This PR looks like put everything from include/ck_tile/ops to include/ck_tile/device/ops, why this is needed? I strongly against this change, there are lot of out-side project depends on include/ck_tile/ops file structure, this PR will break them. And the script remod.py is also depending on original file strucuture

[aosewski]

@carlushuang With current CK-Tile file structure there's a big mess with clear separation of API and operators implementation. Currently our examples directory serve multiple purposes:

1. Examples serve as operator usage/configuration example - this is what they should be.
2. Examples contain tests - this is not OK.
3. Examples contain user host API and device instance & instance code generation- this is also not OK.

By clear separation of device operator host API we got multiple benefits.

• We could easily reuse this API in appropriate tests directory without the need of duplicating code. Using shell scripts is not a good, reliable and readable (also in terms of error reporting) practice to test code. We should strive to leverage unit-tests structure to test our code.
• Having directory with just host API (here we could have operator instance selection heuristics and instance code generators) is clear for end-users. Short glance at this directory and user know what is supported and what not. This is also a signal for end-users that this is not just a project in alpha state but rather more serious library with thoroughly considered design.

If adding another level of directory hierarchy may break things, maybe we could move device operator host API & instance code generation logic under /ops//api subdirectory ? This way end-user would still include just single header like /ops/gemm/gemm.hpp.

@illsilin @geyyer What do you think about such refactor ?

[carlushuang]

@aosewski I think if following this way, the include/ck_tile will not only contains device template, but also contains some extra logic like kernel selection/host-api, which is outside the scope of a device template library.
Originally I purposely put the host-api into example folder only because this violate the design of ck include folder as a template device library. e.g. if people want to include CK as device template header, they only need the device template, not others.
Hence I didn't place the folders under include/ck_tile. And I still this is the cleanest way to do so