[Feature] Refactoring to plugin architecture

[ruanwenjun]

Description

As describe in README.md, InLong is aim to use plugin architecture. Currently, in my view, the code is still coupling.
This make InLong is not scalable enough, and make the contributor hard to contribute to new module.

It's better to define some plugin definition modules, e.g. sort-plugin-api, dataproxy-plugin-api, define the service provide interface in these modules and use SPI mechanism to load the plugins, once user hope to add a new implementation, they can simply create a new submodule and implement the plugin api.

Use case

No response

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dockerzhang]

inlong-manager should be included.

[dockerzhang]

agent guide is available, please see how to write plugin agent.

[dockerzhang]

agent/manager/sort/dashboard is plugin architecture now. the guide is at https://inlong.apache.org/docs/next/design_and_concept/how_to_write_plugin_agent.
so close this issue.