fix: more granular Applicant, Proposal & Property types

[jessicamcinchak]

Summary of key changes:

• data.applicant
  • add type
  • add interest
  • add ownership
  • agent contact info is cleaned up to not repeat sameAsSiteAddress as that never applies to an agent
• data.property
  • move localAuthorityDistrict & region to outer level rather than inside address
  • adds titleNumber & EPC (conditional on region = London)
  • update constraints type (adds PlanningConstraint enum, but not referencing yet)
• data.proposal
  • repeat boundary with redline info
  • add date & retro.date
  • add details catchall (also conditional on region = London, still a lot of questions here but this feels like a decent start)
  • add VehicleParking enum
  • update projectType enum values with more granularity (i've covered most popular project types, but likely still missing a lot here which will need to eventually be added in-full)

Still a few more ? overall than I'd like, hoping those get tightened up as we work through specific questions here: https://docs.google.com/spreadsheets/d/1sBJ48u_BKg5_i2VjEjGORFxlBJVlXdUyFJpiliZw2-s/edit#gid=0

[DafyddLlyr]

A few questions, a few comments. Pretty much all can be fixed forward I think if you'd rather 👍

[DafyddLlyr]

I think this is actually probably redundant - it looks like a way that Editors get an optional value for number.

Could we just have titleNumber?: string or titleNumber?: { value: string } to represent this block?

[DafyddLlyr]

Similarly, this could be modelled as -

EPC?: {
  value: string;
  onlyAppliesToSomeProperties: boolean;
}

[jessicamcinchak]

My initial thinking here was that an optional value alone loses the distinction between "[I know] The property does not have one" and "No [I don't know if my property has one]" ?

This one is definitely still WIP in the spreadsheet, so going to fix-forward here as needed.

[DafyddLlyr]

So it looks like the plugin doesn't natively support a GeoJSON format which is a shame https://github.com/ajv-validator/ajv-formats

Elsewhere we've used this package to type GeoJSON - https://www.npmjs.com/package/@types/geojson

We could import this and just use this type? It will probably bloat the schema a fair bit but as it's machine-readable only maybe it's not a big issue? (it's would be nice if we could split up the schema files automatically).

[DafyddLlyr]

Actually, looking at the raw type it's a fair bit simpler than I anticipated - maybe not a bad way to go? https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/geojson/index.d.ts

[jessicamcinchak]

just tried both of these and got a flurry of build issues, so transferred to an issue instead for now: #41

[DafyddLlyr]

nit: Just as this is a shorthand key, could we add an @decription above this line also?

[jessicamcinchak]

i don't know what it's shorthand for yet, will revisit !