Use attached process data for Windows by default

[skvl]

This is a proposal.

From Inside NT's Asynchronous Procedure Call:

Asynchronous Procedure Calls (APCs) are a fundamental building block in NT's asynchronous processing architecture.

Basically, APCs allow user programs and system components to execute code in the context of a particular thread and, therefore, within the address space of a particular process.

From Windows Vista APC Internals:

Normally, a Windows thread executes in the context of the process which created it. However, it is possible for a thread to attach itself to another process, which means it will execute in its context.

From Windows Kernel Internals. Thread Scheduling p. 30:

Allows a thread in the kernel to temporarily move to a different process’address space
* Used heavily in VM system
* Used by object manager for kernel handles
* PspProcessDeleteattaches before calling ObKillProcess() so close/delete in process context
* Used to query a process’ VM counters

Currently in src/plugins the attached_proc_data used more heavily then proc_data:

$ grep -rnI "\->attached_proc_data" src/plugins | wc -l
113
$ grep -rnI "\->proc_data" src/plugins | wc -l
39

Except filetracer/linux.cpp and syscalls/linux.cpp the usage of proc_data seems error-prone.

Current implementation of win_get_current_attached_process implementation already do the checks:

• If the thread has attached process context the context used to get the EPROCESS.
• Otherwise current process's EPROCESS.

So I propose to use attached_proc_data by default and add method like current_proc_data to refer to _KTREAD.Process.

Thus it would be possible to eliminate all confusing checks about OS and use some sort of fail safe defaults. Though it would be possible for one to decide which one to use.

cc: @disaykin @icedevml