Add a --enable-dev-mode to enable everything

[elichai]

When modifying the internals I usually want to run all the tests and make sure that I don't break any of the modules.
but I never remember exactly if module comes before or after the module name (i.e. --enable-module-ecdh vs --enable-ecdh-module) and it's a lot to enable all modules.

So I added a short simple flag --enable-dev-mode that enables everything.
(If we want to make it more configurable, we can set all default values before, then process dev-mode, and then process the rest of the flags without any action-if-not-given, so that further flags can override the default dev-mode, but because it's for development I think this is currently enough)

This also fixes the fact that we've assigned use_experimental but used enable_experimental.

[real-or-random]

Hm I was wondering why this has been working then since ever. The reason is that enable_experimental is automatically assigned, and so we don't need to set this at all here...

See https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Package-Options.html or https://autotools.io/autoconf/arguments.html .

And there's no reason to have sometimes use and sometimes enable. we may want to do some cleanup in our configure.ac. That does not need to happen in this PR but to keep it consistent for now, it may be cleaner to check for use_experimental below instead of making the change here.

[real-or-random]

Concept ACK

[sipa]

Concept ACK

[jonasnick]

concept ACK

(even more useful in secp-zkp)

[practicalswift]

Concept ACK

[real-or-random]

This currently disables all the options if you pass --disable-dev-mode or equivalently --enable-dev-mode=no. But these should just be noops.
(https://autotools.io/autoconf/arguments.html is a nice document explaining how autoconf works here)

I think it would also be nice to first handle dev-mode and then other options, so you can enable all modules but then disable a particular one.

[real-or-random]

@elichai I still think this very useful. Are you planning to work on this? If not, maybe someone could take over.

[real-or-random]

Closing in favor of #1079.