Rename all internal modules to mapl_<Name>_mod convention

[tclune]

Summary

MAPL module names currently follow the mapl_<name> convention. This is causing namespace collisions when a module wants to export a public entity (e.g., a derived type) with the same name as the module itself. The _mod suffix convention is a well-established Fortran idiom to avoid this conflict.

Proposed Change

Rename all internal (non-umbrella) MAPL modules from:

• mapl_<name> → mapl_<Name>_mod
• mapl_<name>Mod → mapl_<Name>_mod (legacy partial naming, normalize)
• mapl_<name>_mod with wrong prefix casing → fix casing

Naming Convention

• Prefix: always lowercase mapl_
• Body: CamelCase
• Suffix: always lowercase _mod

Example: MAPL_GridComp → mapl_GridComp_mod

Umbrella Modules (excluded from renaming)

Umbrella modules — those that only re-export entities via USE statements — are excluded since client code uses them directly. These will be identified semi-automatically (modules whose bodies consist only of USE, PUBLIC, PRIVATE, and IMPLICIT NONE statements).

Known umbrella modules include: MAPL, MAPL_Constants, and others to be confirmed during implementation.

Motivation

• Eliminates the naming conflict between a module and its exported public entities
• Establishes a clear, consistent, and idiomatic Fortran naming convention across the whole codebase
• Brings legacy *Mod-suffix modules into alignment with the new standard

Scope

• ~540 module definitions across the MAPL source tree
• All internal USE statements must be updated consistently
• File names do not need to change (only the MODULE statement and USE statements)
• No impact on client code (which only uses umbrella modules)
• Build system (.mod file names) will change accordingly; clean rebuild required

Implementation Plan

1. Semi-automatically detect umbrella vs. non-umbrella modules
2. Build a complete rename mapping (old name → new name)
3. Apply renames to all MODULE declarations and USE statements via script
4. Manual review of edge cases where CamelCase is ambiguous
5. Verify build succeeds