`threading.Thread`'s group parameter is a nuisance

For some background: on DPO, someone suggested a threading.run function. I was in favor of the idea on the basis that threading.Thread has a clunky constructor. That aside, I think we can try to improve it.

In particular, the group parameter is an annoying sharp edge. It's the first positional argument, so threading.Thread(my_function) doesn't work, and instead you get a cryptic error message saying group argument must be None for now. I've fallen victim to this many times.

The docs say that group is reserved for a future ThreadGroup class:

group must be None as it is reserved for future extension when a ThreadGroup class is implemented.

I did some digging, and it seems it was proposed to add a ThreadGroup back in 2014: #66212. Many were not in favor of the idea, as it looked like a worse version of ThreadPoolExecutor. Other than the existence of this parameter, I can't see much reason to ever add a ThreadGroup. So, what do we do about group?

I think it's feasible to deprecate and remove it entirely. We can do this by changing the default group parameter to a private sentinel value, and then if a user passes anything to it (including None), we emit a deprecation warning. In five years, we remove the parameter, making target the first positional parameter and thus allowing Thread(my_function) to work.

Most people use the threading.Thread(target=...) pattern for creating threads, and they won't be broken by a deprecation or a removal. For the people who do use the Thread(None, function) pattern, migrating is fairly trivial.

What do others think? Would a removal result in too much breakage?

先從 threading.Thread 建構函式及其相關文件開始，接著檢視 issue #66212 和連結的 DPO 討論，以了解先前的設計考量。確定現有位置引數用法的相容性、警告和遷移行為；只有在是否以及如何將 group 參數標記為已棄用並移除這點上達成共識後，才算完成。