Add historical ADRs

[GDYendell]

Closes #304

Note: This PR made heavy use of claude code to scan the history for changes that warranted an ADR and in the initial draft.

@coretl, @gilesknap These required some editing and I need to do a second pass review, but I think this has turned out great

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.69%. Comparing base (e8d59fb) to head (9b5725b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #305   +/-   ##
=======================================
  Coverage   90.69%   90.69%           
=======================================
  Files          70       70           
  Lines        2535     2535           
=======================================
  Hits         2299     2299           
  Misses        236      236           

☔ 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.

[coretl]

I think the larger ADRs (like 9) are about right, there's a similar one in ophyd-async:
https://github.com/bluesky/ophyd-async/blob/main/docs/explanations/decisions/0009-procedural-vs-declarative-devices.md

However the smaller ones (like 5) are a bit wordy, and could do with cutting down. The example for those doesn't really add anything to the code. A similar one in ophyd-async:
https://github.com/bluesky/ophyd-async/blob/main/docs/explanations/decisions/0011-buffer-updates-camonitor.md

I also wonder if it makes sense to write in the present tense rather than the past tense to keep compatibility with future ADRs we will write at the time of writing the feature