feat(data-modeling): Create Assessment.Survey collection type

[ll-zerr]

Resolves #46

Creates Assessment.Survey collection type

[jtfairbank]

praise: @ll-zerr great job! one quick suggestion, and you've inspired a larger architecture question as well. might be good to discuss that one when your squad gets together (tho do post the highlights from the discussion on here for the rest of us)

[jtfairbank]

question(blocking): I initially thought "Assessment.Survey" was too broad in terms of naming, since we might have other types of Assessments in the future (Needs Assessment, Capacity Assessment, Interest Survey, etc). But then I realized that most of them would probably use a lot of the same underlying code to generate the surveys, and simply map to a different data types (Need, Capacity, etc). Would it make more sense to:

1. Keep this broad and consolidate any of our assessment / survey code here?
2. Make this thin (i.e. "NeedsAssessment.Survey" and use components to capture reusable code?
3. Something in the middle.

@TravisAlmey @madcalf would love your input here as well!

[TravisAlmey]

My personal opinion would be to keep this relatively thin. I might rename this to NeedsAssessment and then when we do run into common functionality split out the needed functions into reusable code. I am of the opinion that splitting out things into reusable funtions should be done afterward unless you have other tasks on your roadmap that specifically would need the shared code.

I guess this is an extension of the YAGNI priciple: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[jtfairbank]

@TravisAlmey makes a lot of sense to me! @ll-zerr what do you think about this approach? So we'd have something like NeedsAssessment.Survey and NeedsAssessment.Need collection types in this module.

[ll-zerr]

Sounds good to me.

[ll-zerr]

@jtfairbank , I created a new api for the survey collection type to align with the naming suggested. It should be noted that all references to the previous api and the survey collection had to be removed from the modeling prior to creating the new api to avoid errors when updating the types.

[jtfairbank]

@ll-zerr looks great! Can you work with @Lovelyfin00 to make sure that process of "renaming" a collection type is documented for folks who might need to do it in the future? A section towards the bottom of the readme, or a markdown file in a /docs folder seem like a good place for it, but I'll defer to where @Lovelyfin00 thinks is best!

[jtfairbank]

Praise: @ll-zerr approved the PR!

Todo: There are some conflicts preventing me from merging. Can you rebase saga into this branch to resolve them? Lmk if you need help and we can do it together during one of the tech hangouts this week!