feat: shared and static library targets

[perazz]

🔧 Add support for building shared libraries via [library] type option

This PR introduces a new manifest option to control how libraries are built:

[library]
type = "shared"      # Build shared libraries (.so, .dylib, .dll + .lib/.def on Windows)
type = "static"      # Build a static archive (.a or .lib)
type = "monolithic"  # Default: build a single static archive for the root package and all dependencies

Key features for type = "shared":

• Each package in the dependency graph is compiled into its own shared library (lib<package>.{so|dll|dylib}).
• Properly resolves and links dynamic library dependencies via a topologically sorted package dependency graph.
• Cross-platform support: .so on Linux, .dylib on macOS, .dll + .lib + .def on Windows.
• Install integration: when install.library = true, shared libraries are installed to the lib/ directory.
• fpm run automatically updates LD_LIBRARY_PATH (or platform equivalent) to find runtime libraries.
• Naming convention is future-proof for later versioning extensions.

📚 documentation available at fortran-lang/fpm-docs#164

Address #681 #655, Supersede #1050.

cc: @certik @urbanjost @arteevraina @henilp105

[perazz]

• Replaced shared = true with a unified type = "monolithic" | "static" | "shared" string-based key
  → keep the manifest similar to meson.buildtype or cargo’s crate-type, we can later extend it to simultaneous configs.
• Added tests for complex configurations
  • Empty libraries
  • Dependency graphs with circular/shared library references
• On Windows (MinGW/Cygwin), generate import libraries (.lib / .dll.a) and definition files (.def)

cc: @zoziha

[zoziha]

This looks really complex. Thank you for your work, @perazz . Since all the tests have passed, I think this PR can be merged after waiting for potential review comments from others.

Additionally, I've left some comments.