Restructure BAYS_AE

[DCEW]

Second attempt on this PR taking into account previous comments

• no icons in the TOC
• limitations section last
• tables that can be created from the CSVs have been (leaving the level/description one as MD since I don't think we use this elsewhere?)

Relates to #94
Closes #55

Previous PR is here - recreated entirely due to git issues.

[yiwen-h]

Changing the format of three of our key reference files from YAML to CSV is a decision that needs wider discussion before it is enacted in a pull request.

If we change them to CSV we'll need to update the pages that refer to them, e.g. calculation-traceability-matrix.md, classification-register.md and conversion-archetypes-catalogue.md. As it stands, your PR will break these pages.

YAML is arguably a better format because of the structure of the data. I'm sure it is also possible to load and filter the data from YAML format as well as CSV. I can take a look into this if you would like.

Welcome thoughts from @paulseamer on the preferred file format for these reference files

[yiwen-h]

Your code references format_list_cells which is not yet in the repo so I can't run it locally - we need to get https://github.com/The-Strategy-Unit/open-plan-docs/compare/61-yaml-format in first

[DCEW]

Your code references format_list_cells which is not yet in the repo so I can't run it locally - we need to get https://github.com/The-Strategy-Unit/open-plan-docs/compare/61-yaml-format in first

Yes, I messaged Rhian about this as I can't render locally with Paul's formatting changes.

[yiwen-h]

My other initial thoughts (not full code review yet):

We need to be more DRY as there are loads of these functional area pages - worth defining a function for loading and filtering the reference files that we can reuse for each of them? (This can be handled in a later issue/PR but worth considering before we start applying the changes in this specific PR to all the functional area pages)

The way the files are filtered
str.contains('|'.join(['MINOR', 'BAYS']) is not robust (what if we change the names or add new assumptions?) - better to list the specific assumptions to display on the page and name them directly. I think this is important to address in this PR and in all other functional area pages.

[DCEW]

Ok, I've gone back and altered the code that renders the assumptions table to make it more programmatically derived - avoiding the more brittle approach from before.

Further DRYing out can be a focus for a future PR (I've made a new issue for it).

NB the diff also includes the incoming changes from PS as I had to rebase (I think that's why anyway).