📚 Add developer guide from wiki content

[GeigerJ2]

NOTE: Merge after #7265.

Rendered view:
https://aiida--7215.org.readthedocs.build/projects/aiida-core/en/7215/developer_guide/index.html

The content from the wiki moved into the previously existing (but excluded from the docs build) docs/source/developer_guide with the help of Claude Code. Some outdated information was already removed (see below).

Everything manually verified, updated, and brought up to speed with current practices and our technical setup.

The overall structure and content is as follows. I already pinged people who might potentially have a say in each section (assuming nobody wants to go through the whole thing, even though I think it's quite informative now, so please be my guest, if so =):

Contributing

• development_environment.md @danielhollas
  • setup (fork, clone, uv sync), environment isolation (profiles, worktrees, Docker), running tests, pre-commit hooks, WSL, useful verdi commands
• coding_style.md @danielhollas, @mbercx
  • pre-commit hooks overview, PEP 8 / Google style, AiiDA conventions (file ops, headers), Python style (f-strings, pathlib, type hints)
• writing_tests.md @khsrali
  • testing philosophy, test types (local, benchmark, system, stress), setup, running tests, markers, transport/RabbitMQ tests
• writing_documentation.md @khsrali @mbercx
  • building docs locally, Divio doc organization, style guide (tone, formatting, MyST, RST), cross-references, code segments, docstring format
• pull_requests.md @agoscinski
  • making a PR, CI requirements, commit guidelines (50/72 rule, emoji prefixes), merging strategies
• code_review.md @agoscinski
  • standards, communication, review checklist

Maintainer guides

• deprecations.md @mbercx
  • gathering usage info, deprecating the CLI, deprecating the Python API
• dependency_management.md @danielhollas
  • pyproject.toml / uv.lock / environment.yml, AEP 002 prerequisites, updating deps, CI, constrained deps
• database_schema.md @mbercx
  • storage backends, key locations, creating Alembic migrations, testing migrations (PostgreSQL/SQLite), config migrations
• releases.md @mbercx
  • how releases reach users, branching strategy, semver, pre-release testing, 9-step release procedure, conda-forge, release CI workflows
• issue_triage.md @agoscinski
  • first response, choosing labels, assigning developers, closing issues

Core internals

• internals.md @mbercx
  • package structure, key design concepts (provenance, process/node duality, plugins, public API), class hierarchies, daemon
• design_evolution.md @mbercx
  • version-by-version design decisions from v2.8 down to v0.9 (content up to v2 was taken from the wiki unchanged)

---

Removed outdated content

• Python 2 compatibility notes, __future__ imports guidance, Python 2/3 dual support instructions
• Django backend — the entire Django ORM/South migrations section in database_schema.md (Django backend was removed in v2.0; only SQLAlchemy/Alembic remains)
• Travis CI — references to Travis CI builds/deployment (replaced by GitHub Actions)
• BitBucket — references to the BitBucket-to-GitHub migration
• plugins.rst — deleted entirely; all 6 referenced files were missing, and plugin dev docs now live in howto/plugins_develop.rst
• virtualenvwrapper — old virtualenv setup instructions (replaced by modern venv/uv workflow)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.86%. Comparing base (faf0969) to head (35a9309).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7215      +/-   ##
==========================================
- Coverage   79.86%   79.86%   -0.00%     
==========================================
  Files         566      566              
  Lines       43925    43925              
==========================================
- Hits        35077    35075       -2     
- Misses       8848     8850       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[khsrali]

I agree it makes sense to have this as part of docs