drivers: sysreset: revert support for args in request

drivers: sysreset: revert support for args in request

This reverts:
- commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl
  option is available")
- commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not
  supported")
- commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset")
- commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command
  documentation")
- commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode
  for QCOM SoCs")
- commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take
  arguments")

There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig:
enable psci based sysreset") due to commit 02ef1859b44f ("configs:
Resync with savedefconfig"), but the conflict resolution was trivial.

The args support for the sysreset uclass contains a logic bug. The first
sysreset device implementing the request_arg callback will consume the
args, not support the specified arg and thus return -EPROTONOSUPPORT
which will stop the iteration over all sysreset devices.

This is an issue if one has multiple sysreset devices and each with
support for different (valid) args. If a sysreset device implements a
-dummy argument and another -foo and a user calls reset -dummy from the
U-Boot CLI, it'll depend on which sysreset device will be attempted
first. If it is the one implementing -foo, it'll return it doesn't
support the argument with -EPROTONOSUPPORT in which case the device
implementing -dummy will never be attempted and instead we'll do a cold
reset which is very likely not what's expected from the user.

Casey suggested[1] we revert this and start from scratch again with a
different implementation instead.

[1] https://lore.kernel.org/u-boot/77ff0f56-5c3b-42e7-bdd1-bf90296da900@linaro.org/

Acked-by: Casey Connolly <casey.connolly@linaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>