tests/sys/kern/procdesc.c: mark grandchild var in pdopenpid_capmode() as volatile

[kib]

Summary

The variable is written in the child process which shares the address
space with the parent.  The data flow must not be optimized by a compiler.

Fixes:  ddf62c83fc0a ("sys/tests/kern/pdopenpid: pdopenpid(2) is allowed in cap mode")

[markj]

Why not use atomics?

[kib]

In D59282#1360563, @markj wrote:

Why not use atomics?

I believe that volatile matches the issue I need to prevent, while atomic is not.
There is no race involved there, the accesses are serialized by the residual _exit() call in the child vs. the wait for P_PPWAIT condition to resume of the execution in the parent.
So the problem is that the grandchild variable could be modified in the way that cannot be deduced from the flow control visible to the compiler, and not a race.

The C23 standard explicitly describes the situation as the subject of the volatile semantic:

An object that has volatile-qualified type may be modified in ways unknown to the implementation
or have other unknown side effects. Therefore, any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.4. Furthermore,
at every sequence point the value last stored in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors mentioned previously.150) What
constitutes an access to an object that has volatile-qualified type is implementation-defined.