Rename cmake:noconf to cmake:indirect

In D44509#1017273, @arrowd wrote:

In D44509#1017272, @makc wrote:

Moreover, nothing in the ports tree needs plain cmake:env without dependency on cmake.

That makes sense. All right, let it be noconf then.

In D44509#1015937, @arrowd wrote:

Can't agree with Daniel here. USES=cmake should be the most common case which is "depend on cmake executable and use it for configuring the project'. The cmake:build might be misleading - I'd think of it as the same as just cmake currently is.

In D44509#1015772, @arrowd wrote:

I'm still unsure if it is worth it. Anyways, a bit of bikeshedding - the seemingly similar python.mk option is called env. Maybe follow pythom.mk here?

Apply Ade's suggestions and convert a couple of ports for example.

In D44509#1015389, @arrowd wrote:

In D44509#1015388, @makc wrote:

This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core.

I don't see this a big problem. I doubt there would be another disruption caused by renaming the port again.

In D44509#1015209, @adridg wrote:

With kde@ hat on, but only nit-picking on language in comments. I think Gleb's question in the PR is relevant, though: what does this do-or-simplify that BUILD_DEPENDS does not?

/
This hides from consumers that cmake port has been split and cmake binary is provided by devel/cmake-core. Secondly, cmake:noconf allows ports to use CMAKE_* helpers from cmake.mk, although I don't know whether pep517 (or meson, cargo, etc.) should use them, but several ports which use cmake for a side target could be simplified.

Update diff with full context.

Around 500 ports define TEST, DEBUG, LTO options. What are implications for them?

If some subpackages have been disabled via options, should we force to build them anyway if they are listed in TARGET_SUBPACKAGES? What if other ports rely on particular subpackage?

Add @qt5

trim patch

Ship it!