Our current implementation for extracting information about common block
required traversal of FIR which was not ideal but previously there was
no other way to obtain that information. The `[hl]fir.declare` was
extended in commit https://github.com/llvm/llvm-project/pull/155325 to
include storage and storage_offset. This commit adds these operands in
`fircg.ext_declare` and then use them in `AddDebugInfoPass` to create
debug data for common blocks.

#167489 did not work properly when MLIR inlining is enabled
(experimental in flang, enabled with `-mllvm -inline-all`).

The reason is that inlining will cause several `fir.dummy_scope` to
coexist inside a same `func.func` (`fir.dummy_scope` of inlined
`func.func` are preserved in order to preserve the relationship between
arguments of the inlined call for better aliasing deductions).

After #167489, the debug info pass creates argument debug info for all
fir.declare with a fir.dummy_scope. This causes arguments from inlined
calls to appear as argument of the procedure where the call was inlined.

To avoid this, only consider that fir.declare are arguments of the
current function if their fir.dummy_scope is the first one created in
the function (fir.dummy_scope cannot be reorder because they have write
effects to the debug memory ressource, and the fir.dummy_scope of the
current functions is always emitted before any calls are lowered, so
before any fir.dummy_scope are inlined).

CHARACTER dummy arguments were treated as local variables in debug info.
This happened because our method to get the argument number was not
robust. It relied on `DeclareOp` having a direct reference to arguments
which was not the case for character arguments. This is fixed by storing
source-level argument positions in `DeclareOp`.

Fixes #112886

Fixes https://github.com/llvm/llvm-project/issues/160907.

When a module is just being used and not defined, we generate it with
decl=true. But if the file/line fields are valid, the module is not
merged with the original and is considered different. This patch avoids
setting file/line/scope in such cases.

This PR builds on https://github.com/llvm/llvm-project/pull/160540 and
allows us to set the `splitDebugFilename` field in `DICompileUnitAttr`.
The changes are mostly mechanical.

I saw some spurious white space in a test that I have cleaned up.

Mostly mechanical changes to add the missing field.

This PR builds on the https://github.com/llvm/llvm-project/pull/158314
and adds the lowering support for `-gdwarf-N` flag. The changes to pass
the information to `AddDebugInfo` pass are mostly mechanical. The
`AddDebugInfo` pass adds `ModuleFlagsOp` in the module which gets
translated to correct llvm metadata during mlir->llvmir translation.

There is minor correction where the version is set to 0 in case no
-debug-version flag is provided. Previously it was set to 2 in this case
due to misreading of clang code.

This is combination of https://github.com/llvm/llvm-project/pull/138149
and https://github.com/llvm/llvm-project/pull/138039 which were opened
separately for ease of reviewing. Only other change is adjustments in 2
tests which have gone in since.

There are `DeclareOp` present for the variables mapped into target
region. That allow us to generate debug information for them. But the
`TargetOp` is still part of parent function and those variables get the
parent function's `DISubprogram` as a scope.
    
In `OMPIRBuilder`, a new function is created for the `TargetOp`. We also
create a new `DISubprogram` for it. All the variables that were in the
target region now have to be updated to have the correct scope. This
after the fact updating of
debug information becomes very difficult in certain cases. Take the
example of variable arrays. The type of those arrays depend on the
artificial `DILocalVariable`(s) which hold the size(s) of the array.
This new function will now require that we generate the new variable and
and new types. Similar issue exist for character type variables too.
    
To avoid this after the fact updating, this PR generates a
`DISubprogramAttr` for the `TargetOp` while generating the debug info in
`flang`. Then we don't need to generate a `DISubprogram` in
`OMPIRBuilder`. This change is made a bit more complicated by the the
fact that in new scheme, the debug location already points to the new
`DISubprogram` by the time it reaches `convertOmpTarget`. But we need
some code generation in the parent function so we have to carefully
manage the debug locations.
    
This fixes issue `#134991`.

The `AddDebugInfo` pass currently has a dependency on the `DLTI` MLIR
dialect caused by a call to the `fir::support::getOrSetMLIRDataLayout()`
utility function.

This dependency is not captured in the pass definition. This patch adds
the dependency and simplifies several unit tests that had to explicitly
use the `DLTI` dialect to prevent the missing dependency from causing
compiler failures.

I am making a CG pass to depend on `FIROpenACCSupport` in #134346.
This introduces a cyclic dependency between `FIROpenACCSupport`
and `FIRCodeGen`. This patch splits `FIRCodeGen` into
`FIRCodeGenDialect` (for FIR CG dialect definition) and `FIRCodeGen`
(for the CG passes).

Now, `FIROpenACCSupport` depends on `FIRCodeGenDialect`,
and `FIRCodeGen` depends on `FIROpenACCSupport`.