Multi-threading can exist at three levels (userland/kernel/CPU) and each are not necessarily linked (a multi-threaded process can run on a single thread CPU and single threaded processes can take advantage of a multi-threaded (a.k.a hyperthreading) CPU.

As far as kernels are concerned, CPU multi-threading/hyperthreading is not really different than multi-core or multi-CPU support.

Process threads are implemented through different APIs under Windows than under Unix and Linux which nowadays are both mostly using POSIX threads. The implementation used to be more complex with the "many to one" model (many software threads bound to a single kernel level thread) or the "many to many" one compared to the model mostly used today "one to one".

There is no difference, time-slicing / scheduling algorithms apply to threads and always did even when all processes were single threaded.

Don't confuse CPU multi/hyper-threading/multi-core (first sentence) and process multi-threading (second one).

There is no such thing as a full process vs a thread execution because threads are not other entities than processes. A process is just a collection of one or more (user level) threads.

No that much. One is some components are shared by the multiple-cores of a single CPU. This can impact performance.

The trend is for processors to have more than one core and for the cores to be multi-threaded. The OS doesn't determine what the hardware is. There is usually no configuration involved although with some high end CPUs like the UltraSPARC T4 and newer are able to switch from multi-thread to single thread mode, i.e. to monopolize all of a core resources to a single process thread.