feat: add Residential Unit types captured via List component

[jessicamcinchak]

Based on:

• https://editor.planx.uk/opensystemslab/residential-units
• https://github.com/theopensystemslab/planx-new/tree/main/editor.planx.uk/src/%40planx/components/List/schemas/ResidentialUnits

Changes:

• Adds residential unit type definitions to ODP Schema
  • Sites within the UK can have data.property.units.residential and/or data.proposal.units.residential
  • Sites within the GLA will have data.proposal.units.residential with possible children new, rebuilt, removed, retained
• Updates existing Prior Approval example (in GLA with 1 rebuilt res unit)
• Residential units introduce a lot of new enums - the type definitions to convert the enum to a typescript value/description pair were adding a lot of clutter to schema type files - so now they're co-located with their enum definition which I prefer (sorry this adds so much noise though!). This refactor does not actually effect the generated schema.json, changes there only reflect newly introduced types

Next:

• Add units.residential types to minor, major and other applicable examples

[jessicamcinchak]

Add example ODP Schema payload for Minor Planning Permission

[DafyddLlyr]

Looks good - one minor language question that can be addressed here, or discussed later.

Co-locating enums and types seems like a good call 👍

[DafyddLlyr]

What's the reason this isn't strictly an Entity[]?

[jessicamcinchak]

This is a bit of a weird relic.

You'll find it in existing examples like this (constraint values which don't map to a single Planning Data dataset etc):

{
  value: 'designated',
  description: 'Designated land',
  intersects: true,
  entities: [],
},

I think it was a strategy to require entity when intersects is true. But we could also make entity optional, then enforce entities: Entity[]. I'll revisit this one in another PR as a number of other examples will have to be updated!

[DafyddLlyr]

Thanks for the explanation 👍

[DafyddLlyr]

Quick naming question - do we want to have "UK" / "National" just to be implicit in all these types, with subcategories based on them?

SoTenureType is always assumed to be national unless prefixes/suffixed by a region? e.g. GLATenureType or TenureTypeGLA

Main reason to flag this would be if something is currently national (e.g. Materials), but later becomes more distinct for a region it would mean changing the definition of the original type + adding a new one (e.g. MaterialsUK + MaterialsScotland - a breaking change) vs just adding a new type (MaterialsScotland - a minor change).

[jessicamcinchak]

This is a good question. In my mind, I'm using the UK prefix for specific cases when the GLA & UK categories have no overlap, which feels a little different than cases where the GLA categories extend national categories.

But you're right that this could very well create unnecessary breaking changes later. I'll open a follow-up re-naming PR before we do a proper release to remove the UK prefixes and make all of this consistent (it's going to touch a lot of files)!

[DafyddLlyr]

Yep this seems like the best approach here 👍