feat(Cabal, cabal-install): Display -O and -g as numeric levels instead of booleans

[zlonast]

This PR improves the handling of the debug-info and optimization field to ensure consistency between its configuration and CLI representations.

Changes

• Config default: Updated the serialization logic to represent the default NoDebugInfo value as 0 instead of False in ~/.config/cabal/config.
• Internal consistency: Aligned the default DebugInfoLevel between pkgHashDebugInfo and the Parsec instance. This resolves potential inconsistencies when processing manually generated configuration files.
• Parsing fix: Fixed a bug where boolean flags were not being correctly parsed for the debug-info field. The parser now properly handles both boolean and integer inputs.

    -- TODO: [code cleanup] The following is a hack. The "optimization" and
    -- "debug-info" fields are OptArg, and viewAsFieldDescr fails on that.
    -- Instead of a hand-written parser and printer, we should handle this case
    -- properly in the library.

    -- TODO: The following is a temporary fix. The "optimization"
    -- and "debug-info" fields are OptArg, and viewAsFieldDescr
    -- fails on that. Instead of a hand-written hackaged parser
    -- and printer, we should handle this case properly in the
    -- library.

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[Mikolaj]

@ffaf1 notices this seems to change the behaviour of cabal (namely, it's output). If so, a different PR template should be used, which asks for a different set of tasks.

Would it be possible to add a test that prints the -O and -g things? Preferably in an early commit, so that it illustrates the modification, showing how it requires a change in the test result.

[Bodigrim]

It seems it needs a rebase now.

[zlonast]

@Bodigrim yes, I updated it

@Mikolaj add test for prints the -O and -g things

[Mikolaj]

I don't pretend to have read the whole newest diff, but it seems solid overall. Thank you.

[philderbeast]

On this branch (and not on the master branch), there seems to be two conflicting -g options:

$ cabal run cabal-install:exe:cabal -- build --help
...
Usage: cabal build [TARGETS] [FLAGS]
...
Flags for build:
...
 -g, --ghc                      compile with GHC
...
 -g n or -gn, --enable-debug-info=n
                                Emit debug info (n is 0--3, default is 0)
...

Is -g treated differently than -g n or -gn?

[philderbeast]

If the -g option is re-associated with debug info then this pull request fixes #2056.

[zlonast]

I think we can simply redefine the flag, and few people will notice, since it doesn't appear in libraries or executables.

Those who do notice will now use the full flag. As I understand it, these are the people who manually enter flags in the console.

Currently, this is mostly LLM, which makes this change even more valuable for them.

[philderbeast]

Can you please mention that the short -g flag was previously associated with --ghc?

[zlonast]

Updated the changelog