wifi: rtw89: load TX power related tables from FW elements

wifi: rtw89: load TX power related tables from FW elements

The following FW elements are recognized, and then the valid entries
in them are loaded into SW struct case by case.
* TX power by rate
* TX power limit 2 GHz
* TX power limit 5 GHz
* TX power limit 6 GHz
* TX power limit RU 2 GHz
* TX power limit RU 5 GHz
* TX power limit RU 6 GHz
* TX shape limit
* TX shape limit RU
One single firmware file can contain multiples of each of the above FW
elements. Each of them is configured with a target RFE (RF front end)
type. We choose one of the multiples to load based on RFE type. If there
are multiples of the same FW elements with the same target RFE type. The
last one will be applied.

We don't want to have many loading variants for above FW elements. Even if
between different chips or between different generations, we would like to
maintain only one single set of loadings. So, the loadings are designed to
consider compatibility. The main concepts are listed below.
* The driver structures, which are used to cast binary entry from FW,
  cannot insert new members in the middle. If there are something new,
  they should always be appended at the tail.
* Each binary entry from FW uses a dictionary way containing a key set
  and a data. The keys in the key set indicate where to put the data.
* If size of driver struct and size of binary entry do not match when
  loading, it means the number of keys in the key set are different.
  Then, we deal with compatibility. No matter which one has more keys,
  we take/use zero on those mismatched keys.
  If driver struct is bigger (backward compatibility):
  	e.g. SW uses two keys, but FW is built with one key.
	Then, put the data of FW(keyX) into SW[keyX][0].
  If binary entry is bigger (forward compatibility):
  	e.g. FW is built with two keys, but SW uses one key.
  	Then, only take the data of FW(keyX, keyY = 0) into SW[keyX]

Besides, chip info setup flow is tweaked a bit for the following.
* Before loading FW elements, we need to determine chip RFE via efuse.
* Setting up RFE parameters depends on loading FW elements ahead.

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/20230920074322.42898-8-pkshih@realtek.com