Add file-stateful and stateless / global stateful check markers

[soon]

This is a subtask of #4869, because CheckCloneService uses these markers to create appropriate clone for each check type.

This is also a subtask of #4870

In this task two markers should be added:

1. stateless / global stateful marker (e.g. OneCheckInstancePerApplication)
2. file-stateful (e.g. OneCheckInstancePerThread or OneCheckInstancePerFile)

[soon]

Previously, when I told about file-stateful checks I always use OneCheckInstancePerThread interface name.

Now I'm not sure if this is correct name. The OneCheckInstancePerThread says about implementation details, while OneCheckInstancePerFile says about the expected behavior.

@romani @rnveach @sabaka @Vladlis What do you think? I'm suggesting the OneCheckInstancePerApplication and OneCheckInstancePerFile names, however, there might be other options, like SingleCheckInstance, ThreadLocalCheck and so on.

[rnveach]

@soon Naming is small problem, as logic is more important right now since we aren't in PR stage.

OneCheckInstancePerThread

It depends on what is in a thread as we haven't seen any PRs for your threading implementation for Checker, which I asked if we could start a while ago.

OneCheck

Check shouldn't be in name if it can be applied to other modules like AbstractFileSet. It should be Module.

SingleCheckInstance
ThreadLocalCheck

These names sound too technically and not easy to understand, so I don't like them compared to the others.

Application
Thread

These are synonymous, right? We will have multiple threads in the same application, unless I am mismatching your alternative name for PerThread. I am fine with PerThread until I see more of the implementation that will examine these annotations.

[soon]

It depends on what is in a thread as we haven't seen any PRs for your threading implementation for Checker, which I asked if we could start a while ago.

Sorry for the long reply, here is the PR: #4890

Application
Thread

These are synonymous, right?

I don't think so. One instance per application means that the module will not be copied, there will be one instance across the application lifetime. One instance per thread means that the module will be copied when it is used in a background thread.

Probably, you mixed up PerApplication and PerFile and your quote should include File and Thread? I thought again on the differences between PerThread and PerFile and has concluded, that they are similar. I doubt about the PerThread in context of MT TreeWalker, but seems like the PerThread name is still valid. So that, I'm going to use OneModuleInstancePerThread.

[soon]

@rnveach @sabaka @romani So, should we split OneModuleInstancePerApplication into StatelessModule and GlobalStatefulModule? The underlying implementation will be the same, this splitting only adds new information about the check

Then, if we're splitting, we should probably rename OneModuleInstancePerThread into FileStatefulModule

[sabaka]

@soon , I would prefer to split it. Even if two types are handling the same way, they are still different.

[romani]

fix is merged