Rewrite Ordering to use VendorEntityItemId to identify ordered items

Modify ordering to use VendorEntityItemId, from tbVendorEntityItem, as the unique identifier for an item in an order. We currently use entity id, vendor id, and item id, but for multi-order items these are not unique identifiers. Our table structure already has a single Id value we can use for items in an order, so our tables and code should reflect that.
A larger version of the Feature could be to normalize all the inventory tables (for example, tbVendorEntityItem should contain VendorItemId), though that may be a massive undertaking to attempt all at once.

Details:

1) Update tbTransactionSalesOrderDetail, tbTransactionSupplyOrderDetail

• add VendorEntityItemId, as a foreign key to tbVendorEntityItem
  • maybe don't enforce the foreign key, if we ever delete rows from tbVendorEntityItem
• we may be able to delete itemcode, itemid, vendorid, and entityid from these tables
  • that's a much bigger change
  • may impact performance since we would have to join to tbVendorEntityItem for those values
  • if the item code ever changes for a vendoritem, we'd lose the item code at the time of the order

2) Update data models and nhibernate mappings

3) Update stored procedures used by MxConnect

4) Update API calls

5) Update typescript and markup

6) Update integrated UI tests

7) Update SM tasks

8) Update stored procedures used by Server Manager

9) Update any affected reports

------------------------------------

We should consider Full refactor of Order generation at the same time. One specific Item I found was that we are making a call to "_inventoryItemRepository.GetEntityItems" in AbstractOrderCommandHelper.InsertProjectedOrderWithCubeDataForItemList that seems unnecessary since the AutoOrderTypeID value already should exist on the SimpleOrderItem class.

Another reason to do a major refactor is related to CFAMX-3249 where the tbEntityItem rows are actually being updated as part of the Ordering process which seems unnecessary. The fix there was to correct the Triggers to keep NHibernate happy, but ultimately we need to find out if the updates are even necessary and possibly replace some of this NHibernate modeling with simpler, quicker SQL SPs and DTO models.