Fixed #13396 - do not allow checkout to undeployable status types

[snipe]

This fixes a validation issue in the API where you could technically check out assets on creation even if the status label is an undeployable type.

Fixes #13396 (sort of - that part was handled a long time ago, this handled a bug reported in that issue via @StarlessNights related to the API allowing assets to be checked out to users, locations, etc even if the status label type is undeployable.)

[what-the-diff]

PR Summary

• Enhanced Checkout Validation: Introduced a new rule named AssetCannotBeCheckedOutToNondeployableStatus that restricts the checkout of assets that are not ready for deployment.
• Improved Asset Request Management: Applied the new rule in StoreAssetRequest context, boosting the system's robustness by preventing any invalid attempts to checkout non-deployable assets.
• Better Date Comparisons: In Asset.php, the methodology to compare dates has been improved, specifically in the checkInvalidNextAuditDate method for accurate validation of audit dates, helping to avoid any audit-related inaccuracies.
• Updated Format in Hardware View: Made changes in the hardware view's format for last_audit_date and audit_log.created_at, aligning them with a date-time format. It will help maintain uniformity in how these times are presented in the hardware view.
• Improved Test Environment: In StoreAssetTest.php, multiple test setups are updated to use readyToDeploy status while creating assets rather than a generic status, making testing scenarios more realistic and reliable.
• Extended Test Coverage: Added new tests focusing on verifying validation errors when assets in certain non-deployable statuses are attempted to be saved. These new tests will aid in early-stage error identification and overall system reliability.

[StarlessNights]

Tested in the dev.docker-compose.yml environment. An error is returned correctly for all checkout-on-creation API requests I can think of 👍 (with archived/undeployable status labels that is)