tools: moveconfig: do not rely on type and default value given by users

tools: moveconfig: do not rely on type and default value given by users

Commit 96464badc794 ("moveconfig: Always run savedefconfig on the
moved config") changed the work flow of this tool a lot from the
original intention when this tool was designed first.

Since then, before running this tool, users must edit the Kconfig to
add the menu entries for the configs they are moving.  It means users
had already specified the type and the default value for each CONFIG
via its Kconfig entry.  Nevertheless, users are still required to
dictate the same type and the default value in the input file.  This
is tedious to use.  So, my idea here is to deprecate the latter.

Before moving forward with it, there is one issue worth mentioning;
since the savedefconfig re-sync was introduced, this tool has not
been able to move bool options with "default y".  Joe sent a patch
to solve this problem about a year ago, but it was not applied for
some reasons.  Now, he came back with an updated patch, so this
problem will be fixed soon.

For other use cases, I see no reason to require redundant dictation
in the input file.  Instead, the tool can know the types and default
values by parsing the .config file.

This commit changes the tool to use the CONFIG names, but ignore the
types and default values given by the input file.

This commit also fixes one bug.  Prior to this commit, it could not
move an integer-typed CONFIG with value 1.

For example, assume we are moving CONFIG_CONS_INDEX.  Please note
this is an integer type option.

Many board headers define this CONFIG as 1.

  #define CONFIG_CONS_INDEX    1

It will be converted to

  CONFIG_CONS_INDEX=y

and moved to include/autoconf.mk, by the tools/scripts/define2mk.sed.
It will cause "make savedefconfig" to fail due to the type conflict.

This commit takes care of it by detecting the type and converting the
CONFIG value correctly.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>