`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?

Start with the threading.Thread constructor and its linked documentation, then review issue #66212 and the linked DPO discussion for prior design concerns. Determine the compatibility, warning, and migration behavior for existing positional uses; done requires agreement on whether and how the group parameter should be deprecated and removed.