feat: db models and entities

[mbarlow12]

Remove source db model and integrate into OilGasFieldSourceModel (the new "source" table).

• memberships now have a proper foreign key constraint on og_field_souces
  • Future TODO: worth noting that we can definitely hide a lot more of the membership mechanics with a "join through" relationship to get a cleaner mapping between "ResourceModel" -> "OilGasFieldSourceModel"
• entities are almost entirely gone in favor of the stitch-ogsi pydantic models (usage in follow-ups)

I opted to keep "Resourced" declared in stitch-api for now. I wasn't sure how we want to go for getting the flat/view like version of an "OilGasFieldResource". I see 2 initial options:

• construct the view pydantic model ephemerally using existing "resources" table: get resource w/ source data -> call to coalesce/selection module -> flattened view object
  • for this, we'd probably want to add a OGFieldResouceBase to stitch-ogsi that doesn't have the OilGasFieldBase columns
• have an actual db artifact (table or view)
  • we can add all the OilGasFieldBase columns onto the current resources table. then we can use stitch.ogsi.model.OGFieldResource without any other manipulation

[AlexAxthelm]

NB: For DB stuff I prefer singular over plural phrasings (old habit dies hard).