Complete refactor of the 'simpler logging' action_log changes

[uberbrady]

This is a heavily cleaned up take of #16839 - repeating the notes here:

Updated

This is now getting pretty close. The previously-made updates to tests have definitely helped to catch bugs in this implementation, which I'm pretty happy with.

Right now, we should see that there are still a few failing tests. These all boil down to different choices of implementation. Before this PR we weren't quite too rigid about logging things separately when they were created versus checked out. And we weren't too rigid about making sure that the API worked exactly the same as the GUI in these cases. But, should we be?

My opinion - creating an asset and immediately checking it out via GUI or API should both do the same thing - log a 'created' action_log and then immediately a 'checkout' action_log. I think the extra action_log entries make it clearer and easier to 'replay' the history of an object.

To-Do

• I recently introduced - or, rather, sorta re-introduced, the Loggable method saveWithLogAction() (which I think is a dumb name, I should fix it). I should probably apply that across the code base for consistency.
• This probably needs some extensive testing. It touches a lot of the 'heart' of Snipe-IT - the action_log. While it does try to ensure that some type of action_log happens any time the object-in-question gets modified, or if the various logging methods are called, it's possible that something could have been missed, or there are still subtle bugs around.
• We could probably stand to do another squash - as there are a ton of commits. Unfortunately, the vrious 'squash' attempts I've made in the past seem to obscure the fact that the Loggable trait got moved into the Traits sub-directory, which has made later merges much, much harder.
• Because of how git works, some changes that have happened to some of the files that have been deleted keep making those files pop back up when we try and re-merge develop into this branch. It's not always easy to see what the changes were to merge them back into wherever they belong. I've done my fair share of archeology to try and figure that out, but I could've easily missed something.

Next Steps

1. I have two PR's waiting on this one, which will need to be re-pointed and updated to match this new 'style' of handling the action_logs:

• • Move the user-merge behavior into the user and use it where we merge uberbrady/snipe-it#7
• • Get rid of LogListener's LogListener lines uberbrady/snipe-it#8

2. I think once all that is done and everything is merged, it will be the case that the events that we're firing are really only notification-triggers. If that's true, we might be able to fully "de-event" the notifications, and trigger them all directly with ->notify(). if that makes sense. I feel like the Slack/webhook notifications and the email notifications are sufficiently different that I would like to see if it's possible to split them off - but that might only work with the event'ed notifications, and not with the ->notify() based ones.
3. I think this sets us up to do the 'quantitizable' changes that we've been pondering - having one grand-unified method of making all action_log entries makes it much easier to start to treat "quantities" as first-class fields and not simple repetitions.
4. I think this also sets up some of the "Order" and "Purchase Order" additions that we've been considering simpler as well.

[snipe]

Looks like we've got conflicts again, since I deleted some of those controllers in a previous PR.

[uberbrady]

Two additional PR's (and an implicit third) are stacked against this one:

• Switch User-Merge to a direct method on the User object uberbrady/snipe-it#9
• Make Checkout Acceptance and Declined work without events uberbrady/snipe-it#10

Furthermore, once both of those two PR's are merged, we should be able to completely delete the LogListener at that point (as it will be mostly empty) - which would be another PR, but that's easy enough.

[snipe]

Can you resolve the new conflicts and we can go over this today?

[uberbrady]

fix me stray error

[uberbrady]

stray error (and next line) and further below

[snipe]

Looks like you might have missed one:

Call to undefined method App\Models\Actionlog::logaction()

[snipe]

Closing this for now - you're free to re-open it though. (It's a bit old and there are a ton of conflicts.)