Add listing and property fields

[anders-schneider]

Issue

Addresses #227

• This change addresses the issue in full
• This change addresses only certain aspects of the issue
• This change is a dependency for another issue
• This change has a dependency from another issue

Description

This change adds a number of fields to the Listing and Property models, corresponding to fields we have in the Detroit listing spreadsheet but that don't yet exist in the Bloom data model.

#227 (comment) has a full breakdown of how we plan to map the Detroit spreadsheet fields to Bloom data model fields. This change adds all the fields that are indicated by an asterisk (since they did not yet exist in Bloom).

Most of these fields are likely relatively uncontroversial. The most "controversial" additions are amiPercentageMin and amiPercentageMax. In the existing Bloom data model, AMI percentage information is stored at the level of an individual unit, and soon it will be part of the "UnitsSummarized" table. This change adds a separate option: store AMI percentage information at the level of an entire listing. To date, the Detroit data only includes AMI percentage information at the level of an entire listing, so these fields are necessary. As noted in the code comment, though, we'll rely primarily on the unit-level AMI percentage information and only use the listing-level AMI percentage range if the unit-level data is absent.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Prototype/POC (not to merge)
• This change is a refactor/address technical debt
• This change requires a documentation update
• This change requires a SQL Script

How Can This Be Tested/Reviewed?

Applying the generated DB migration is successful, and the backend/core tests pass.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have reviewed the changes in a desktop view
• I have reviewed the changes in a mobile view
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have assigned reviewers
• I have updated the changelog to include a description of my changes