Accessories multimorph2 - multi-morph many-to-many relationships for accessories to users/locations

[uberbrady]

We have some good groundwork in-place for being able to checkout Accessories to both Locations and Users.

But @snipe was looking for the rest of that "connective tissue" to be in place so we can query which accessories are checked out to a User, which accessories are checked out to a Location. Also, from the Accessories side, we will need to be able to see which accessories are checked out to users, which to locations, and also being able to look at checked-out accessories in general, regardless of where they're checked-out-to.

This is the closest I've been able to come to getting something that makes sense here, but I suspect there's a bit more to go.

First off, this establishes the Laravel-standard "morphed-by-many" relationships:

• From Users, we have the accessories() method which works how you expect.
• From Locations, we have the assignedAccessories() method (naming is different to explain the difference between "assigned to this location" and "located at this location"). This also works how you expect.
• From Accessories, we have two more methods:
• • locationAssignments() - which gives which locations this accessory is checked out to
• • userAssignments() - which gives which users this accessory is checked out to.

So that's all the standard stuff, the one weird one I put in was also to accessories, and is called checkouts() which gives you the 'interstitial classresults ofAccessoryCheckout` for the accessory in question. Those can be chased down and may include Users as well as Accessories.

If I have this right - and it's quite possible that I don't - that last place should be the only place where we need to refer to AccessoryCheckout at all - the rest of the relations all return users or locations or accessories as expected.

There are plenty of places in the code that still do refer to AccessoryCheckout and probably shouldn't need to - but I wanted to keep this PR small, and understandable, and not conflate different changes.

Most of my testing was with Tinker - making sure that accessories would properly show the appropriate users, locations, or checkouts. And then making sure that locations and users showed the right accessories that were assigned to them.

This should give us the right tooling to re-introduce the "checkout accessory to location" feature, if I've done my job right.

[what-the-diff]

PR Summary

• Enhanced Clarity in Accessory Checkout Relationships
  The checkouts method in Accessory.php has been revised to streamline relationship mapping, eliminating redundant joins.

• Improved Assignment Features for Locations and Users
  Implementing locationAssignments() and userAssignments() in Accessory.php now facilitates the assignment of locations and users to accessories.

• Refined Accessory Relationship
  By adjusting the accessory method in AccessoryCheckout.php, we've clarified its relationship with the Accessory model.

• Revised Assigned Type Recognition
  The update to assignedType() in AccessoryCheckout.php acknowledges that the assigned type may not always be necessary.

• Potential Fine-Tuning of User Assignment
  A scopeUserAssigned() method has been added in AccessoryCheckout.php, requiring further review to assess its necessity.

• Efficient Management of Accessories Location-wise
  The assignedAccessories() method has been incorporated into Location.php to streamline managing the assignment of accessories to locations.

• Increased Flexibility in User-Accessory Relations
  We've switched the accessories() method in User.php from belongsToMany to morphToMany, which provides more efficient ways to relate users with their accessories.