Added query selector classes, fixed some recurring bugs

Enhancements

This PR is primarily focused on adding some optimizations & cleanup as pre-work to implementing some stellar suggestions from @LawrenceLoz that will be implemented as part of #311 (originally discussed in #303)

• Added new Apex selector classes LoggerEngineDataSelector and LogManagementDataSelector to centralize (almost) all queries throughout the codebase
• Added new Apex class LoggerCache to centralize caching of query results

Bugfixes

• Possibly fixed an issue discussed in #310 with @reitffunk by reverting to only using a UUID for the transaction ID (instead of using System.Request.getCurrent().getRequestId())
• Fixed #313 reported by @jverelst by switching to using a combination of Logger's transaction ID + an incremented counter to dynamically creating unique usernames during tests. This should ensure that the generated username is unique both within a transaction, and across all Salesforce orgs
• Fixed #276 (again) by moving when an email is added to the constant LoggerEmailSender.SENT_EMAILS, which was previously causing test failures in orgs with email deliverability disabled.
  • Scratch orgs also can't have deliverability disabled (very frustrating), so I also separately changed email deliverability to 'System Email Only' in the pkg demo org that's used in the pipeline, which should help ensure everything is working going forward 🤞
• Added missing access to the class LoggerSObjectMetadata to permission sets 'LoggerAdmin' and 'LoggerLogViewer'
  • This solves an issue in orgs where Apex access is enforced - without the class access, the Logger Settings tab/LWC would throw an error on page load
• Changed the approach used to originally to solve #219 by using the User Type (UserInfo.getUserType()) of the user's profile, which seems to be a more stable option than the old approach of checking the profile's user license name
  • This was originally reported months ago by @solo-1234, who encountered this issue again. I was not able to reproduce the issue, but using User Type seems like a better approach anyway, and will hopefully resolve any lingering issues with the Guest User
  • I tried to find an option that didn't rely on a hardcoded String, but so far, have not found any other way to determine it

Metadata Cleanup

• Deleted some deprecated LoggerParameter__mdt records - these were deprecated in v4.7.1, but I forgot to remove them from the repo/package
• Eliminated layer-specific test suites within core - as of v4.7.1, the tests are super fast anyway, so the 'LoggerCore' test suite covers everything + makes maintenance easier
• Moved the 'LoggerLogCreator' permission set back to being part of the logger-engine layer

Async Failures plugin

• Added a missing CMDT record LoggerSObjectHandler.BatchApexErrorEvent for the async failures plugin (and created a new package version that includes the CMDT record)