Allow case insensitive bools

[zlonast]

The .cabal file parser now accepts boolean values in a case‑insensitive manner (true, True, TRUE, false, etc.) without emitting a warning.
Previously only True and False were treated as “standard”, and other capitalisations triggered a parse warning. That warning was introduced in 2008 as a backwards‑compatibility shim to prevent Hackage uploads that would break very old Cabal versions. Since all supported Cabal releases can now handle case‑insensitive booleans, the warning has been removed as unnecessary.

origin commit in 2008: e92d6573#r185301031

research done by @jappeace: https://github.com/haskell/cabal/pull/11716/changes#r3243914138

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[zlonast]

@philderbeast You often make pull requests like this, I'm interested in your opinion on this matter.

[tdammers]

LGTM; comments are not show stoppers, just things I think would be worth considering.

[zlonast]

@tdammers thanks for your feedback!

[Mikolaj]

Could you please clarity what this PR does about -O1 and why (I know it's in the code, but the motivation is not)? How does this relate to the changes from 2008? Thank you!

[zlonast]

@Mikolaj

1. Case-insensitive booleans: The 2008 warning was a compatibility shim for very old Cabal versions. Since we no longer support those, it's safe to remove the warning and allow case-insensitive booleans.
2. -O1 / -g0 rendering: This is a separate change for consistency. I removed the ad-hoc solutions because I couldn't read them.

[Mikolaj]

Thank you for the explanation of the motivation. Makes sense. Would it also make sense to split the -O1 change to a separate PR? Or to a separate commit in this PR?

BTW, does github display it wrong or is the commit "Add NoFlagValue type class" deleting a lot of files?

I'm satisified regarding this question now.

[zlonast]

@Mikolaj sorry i try to switch from git to jj and some how lost

[ulysses4ever]

-O1 / -g0 rendering: This is a separate change for consistency. I removed the ad-hoc solutions because I couldn't read them.

what is the “change” exactly? I still don’t see an answer to Mikolaj’s question above:

Could you please clarity what this PR does about -O1

And I’d like to see this answered in the PR description and the changelog, if there’s a change in behavior (and the commit message, perhaps; it can be a copy-paste). In particular, Is there a change in cabal’s behavior or is it a pure refactoring?

[zlonast]

@ulysses4ever Sorry, you're right, I misread it. I'll make a separate PR.

You're right, it's a refactoring, that's why I chose template B.

I assume ghc is working correctly and suggest using just one -O1 flag instead of the entire set. I also suggest honestly displaying this -O1 flag to the user, instead of true or false.