Refactor POLine model - Schemas

Overview:
In order to simplify the business logic layer and reduce the likelihood of inconsistencies/race conditions/etc. we've decided to refactor the poLine model so that most of the sub-objects (e.g. cost, details, etc.) are merged directly into the poLine schema. The overall structure would stay the same, but these sub-objects wouldn't need to have their own UUID and also would need to maintain a reference back to the poLine. These changes to the PoLine model closely relate to work needed in mod-orders, ui-orders and mod-orders-storage to accommodate these changes.

The end result of this would be that we'll be storing something that looks a lot more like composite_po_line. The few remaining references to other orders sub-objects (e.g. reportingCode, alerts, etc.) are to controlled vocabularies - things that can be referenced by many poLines. Despite the narrowing of the gap between poLine and compositePoLine, for now we'll still maintain the two schemas

The Acquisitions API Listing document provides a little more detail in this comment:

NOTE: po_line now includes: adjustments, claims, cost, detail, eresource, fund_distribution, license, location, physical, source, vendor_detail

Scope:
Update the PoLine model (schemas and examples). Necessary changes to the UI, business logic and storage layers will be addressed in separate stories.

Acceptance Criteria:

• id and poLineId fields are removed from the sub-object schemas listed above
• UUID references to these sub-objects are removed from PoLine and their schemas are included/referenced by the poLine schema instead. (a la compositePoLine)
• examples are updated
• fields in these schemas are transitioned to camelCase if still using underscore_notation.