Revert "mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"

This reverts commit b42c67188c14 ("mmc: sdhci-cadence: trigger tuning
for SD HS mode on SD6HC (v6) PHY").

The reverted patch introduced several issues:

1. Non-standard tuning trigger: The SD Physical Layer Specification
   only mandates execute_tuning for SDR50 and SDR104 UHS-I modes.
   Triggering tuning for SD High Speed mode is outside the spec and
   is handled via a non-standard set_ios_post callback rather than
   through the established SDHCI framework tuning path.

2. Non-standard device tree property: The patch introduced a new
   "cdns,sd-hs-tuning" DT property to opt into SD HS tuning. This
   is not aligned with existing DT bindings and bypasses the standard
   MMC capability negotiation mechanism.

3. Incorrect tunable mode allowlist: The sdhci_cdns6_mode_is_tuned()
   function includes SD_HS, UHS_SDR50, and MMC_HS_400_ES as tunable
   modes. According to the Cadence SD6HC IP User Guide (section 7.5.2,
   Figure 18), tuning is only required for UHS-I SDR104 (SD) and
   HS200 (eMMC). SD High Speed, UHS-I SDR50, and DDR50 only require
   a PHY settings update from the pre-calculation script, not the
   tuning procedure. HS400 transitions through HS200 and reuses its
   tuned DLL value with a partial settings update. HS400ES only
   requires a plain settings update from the calculation script with
   no dependency on HS200 tuning.

4. Tuned state management outside the framework: The patch manually
   tracks tuned DLL state (tuned_mode, tuned_dll_slave_ctrl) and
   restores it across PHY reconfigurations. This duplicates
   responsibility that belongs in the core MMC tuning framework and
   adds unnecessary complexity to the driver.

Reverting to realign the driver with the IP documentation and the SD
Physical Layer Specification.

Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>