wifi: rtw89: introduce helpers to wait/complete on condition

MCC (multi-channel concurrency) related H2Cs (host to chip commands)
require to wait for C2H (chip to host events) responses to judge the
execution result and data. We introduce helpers to assist this process.
Besides, we would like the helpers to be generic for use in driver even
outside of MCC H2C/C2H, so we make a independent patch for them.

In the following, I describe the things first.
```
(A)	C2H is generated by FW, and then transferred upto driver. Hence,
	driver cannot get it immediately without a bit waitting/blocking.
	For this, we choose to use wait_for_completion_*() instead of
	busy polling.
(B)	From the driver management perspective, a scenario, e.g. MCC,
	may have mulitple kind of H2C functions requiring this process
	to wait for corresponding C2Hs. But, the driver management flow
	uses mutex to protect each behavior. So, one scenario triggers
	one H2C function at one time. To avoid rampant instances of
	struct completion for each H2C function, we choose to use one
	struct completion with one condition flag for one scenario.
(C)	C2Hs, which H2Cs will be waitting for, cannot be ordered with
	driver management flow, i.e. cannot enqueue work to the same
	ordered workqueue and cannot lock by the same mutex, to prevent
	H2C side from getting no C2H responses. So, those C2Hs are parsed
	in interrupt context directly as done in previous commit.
(D)	Following (C), the above underline H2Cs and C2Hs will be handled
	in different contexts without sync. So, we use atomic_cmpxchg()
	to compare and change the condition in atomic.
```

So, we introduce struct rtw89_wait_info which combines struct completion
and atomic_t. Then, the below are the descriptions for helper functions.
* rtw89_wait_for_cond() to wait for a completion based on a condition.
* rtw89_complete_cond() to complete a given condition and carry data.
Each rtw89_wait_info instance independently determines the meaning of
its waitting conditions. But, RTW89_WAIT_COND_IDLE (UINT_MAX) is reserved.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221129083130.45708-4-pkshih@realtek.com