Fix profiling migration defaults for large MySQL upgrades

[vishalanandl177]

Summary

• remove default=None from the existing 0003_apilogsmodel_profiling migration and matching model fields while keeping them nullable/blankable
• align historical migration state metadata so makemigrations --check --dry-run stays clean without creating a new migration
• document the 1.2.0+ profiling-column upgrade risk for large MySQL/MariaDB tables, including sqlmigrate, online DDL planning, and fake-apply guidance
• add a regression test that verifies profiling fields remain nullable without Python-level defaults
• bump package/docs version markers to 1.2.2

Closes #121

Validation

• git diff --check
• rg -n "default=None" drf_api_logger\migrations\0003_apilogsmodel_profiling.py drf_api_logger\models.py returned no matches
• J:\projects\drf-demo\venv\Scripts\python.exe -m django test tests --settings=tests.test_settings --verbosity=1 -> 143 tests passed
• J:\projects\drf-demo\venv\Scripts\python.exe -m django makemigrations drf_api_logger --check --dry-run --settings=tests.test_settings -> no changes detected
• J:\projects\drf-demo\venv\Scripts\python.exe -m django sqlmigrate drf_api_logger 0003 --settings=tests.test_settings -> nullable column additions with no defaults
• J:\projects\drf-demo\venv\Scripts\python.exe -m django migrate drf_api_logger --plan --settings=tests.test_settings
• C:\Users\ALKETRON\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe setup.py --version -> 1.2.2