TRI is set to the same value a couple of lines below.

Reverts llvm/llvm-project#155539

Failing on buildbots with:
```
Step 7 (test-build-stage1-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM :: DebugInfo/debug-bool-const-location.ll' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
/home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llc /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll -O3 -filetype=obj -o - | /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llvm-dwarfdump - | /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll # RUN: at line 2
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llc /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll -O3 -filetype=obj -o -
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/llvm-dwarfdump -
+ /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/build/stage1/bin/FileCheck /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll
/home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll:7:10: error: CHECK: expected string not found in input
; CHECK: {{.*}} DW_OP_lit0
         ^
<stdin>:27:54: note: scanning from here
 [0x0000000000000018, 0x0000000000000020): DW_OP_lit1, DW_OP_stack_value
                                                     ^
<stdin>:28:41: note: possible intended match here
 [0x0000000000000020, 0x0000000000000034): DW_OP_reg3 X3)
                                        ^

Input file: <stdin>
Check file: /home/buildbots/llvm-external-buildbots/workers/ppc64le-lld-multistage-test/ppc64le-lld-multistage-test/llvm-project/llvm/test/DebugInfo/debug-bool-const-location.ll

-dump-input=help explains the following input dump.

Input was:
<<<<<<
           .
           .
           .
          22:  DW_AT_decl_line (5) 
          23:  DW_AT_external (true) 
          24:  
          25: 0x0000003f: DW_TAG_variable 
          26:  DW_AT_location (0x00000000:  
          27:  [0x0000000000000018, 0x0000000000000020): DW_OP_lit1, DW_OP_stack_value 
check:7'0                                                          X~~~~~~~~~~~~~~~~~~~ error: no match found
          28:  [0x0000000000000020, 0x0000000000000034): DW_OP_reg3 X3) 
check:7'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:7'1                                             ?                  possible intended match
          29:  DW_AT_name ("arg") 
check:7'0     ~~~~~~~~~~~~~~~~~~~~
          30:  DW_AT_decl_file ("test") 
check:7'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~
          31:  DW_AT_decl_line (5) 
check:7'0     ~~~~~~~~~~~~~~~~~~~~~
          32:  DW_AT_type (0x0000004f "bool") 
check:7'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          33:  
check:7'0     ~
           .
```

Backends like NVPTX use -1 to indicate `true` and 0 to indicate `false`
for boolean values. Machine instruction `#DBG_VALUE` also uses -1 to
indicate a `true` boolean constant.

However, during the DWARF generation, booleans are treated as unsigned
variables, and the debug_loc expression, like `DW_OP_lit0; DW_OP_not` is
emitted for the `true` value.

This leads to the debugger printing `255` instead of `true` for constant
boolean variables.

This change emits `DW_OP_lit1` instead of `DW_OP_lot0; DW_OP_not`.

The test llvm/test/DebugInfo/X86/pr12831.ll was added in 4d358b55fa to
fix the issue with emission of empty DW_TAG_subprogram tags
(https://bugs.llvm.org/show_bug.cgi?id=12831).

However, the test output is not checked properly, and it contains:
```
0x00000206:   DW_TAG_subprogram

0x00000207:   DW_TAG_reference_type
                DW_AT_type      (0x00000169 "class ")
```

The reason is that the DIE for the definition DISubprogram "writeExpr"
is created during the call to `getOrCreateSubprogramDIE(declaration of
writeExpr)`. Therefore, when `getOrCreateSubprogramDIE(definition of
writeExpr)` is first called, we get a recursive chain of calls:
```
getOrCreateSubprogramDIE(definition of writeExpr)
getOrCreateSubprogramDIE(declaration of writeExpr)
...
getOrCreateSubprogramDIE(definition of writeExpr)
```

The outer call doesn't expect that the DIE for the definition of
writeExpr will be created during the creation of declaration DIE. So,
another DIE is created for the same subprogram. In this PR, a check is
added to fix that.

closes #154331 

This PR addresses all minimum changes needed to compile LLVM and MLIR
with the c++23 standard.
It is a work in progress and to be reviewed for better methods of
handling the parts of the build broken by c++23.

Remove "approx-func-fp-math" attribute and related command line option,
users should always use afn flag in IR.
Resolve FIXME in `TargetMachine::resetTargetOptions` partially.

Add operators to shift left or right and insert unknown bits.