Check for valid asset before accessing properties

[snipe]

This fixes a rare 500 that can occur when the maintenances API is loaded, but the asset does not exist anymore. We see this most commonly in the demo, where the data can be unpredictable, and people can end up hitting the demo just as it's resetting/re-seeding.

Fixes RB-3934, RB-3759, RB-3935, and RB-3936.

[what-the-diff]

PR Summary

• Improved Method Returns
  The returns of store, update, destroy, and show methods in the AssetMaintenancesController.php have been modified to be more versatile. These methods can now return either a JsonResponse or an array, expanding the flexibility of their use.

• Better Null Handling
  Safety measures in AssetMaintenancesTransformer.php have been stepped up. Additional checks have been implemented to ensure the non-null status of the asset objects, which will reduce potential errors in the code.

• Enhanced Date Formatting
  We've tweaked how deleted_at and created_at fields in the asset transformation are formatted. They now use the Helper::getFormattedDateObject method, which means that their formatting is more standardized and consistent.

• Inclusion of Updated_at Field
  The asset transformation now has a new updated_at field. Like the other date fields, it uses the same date formatting function. This means our data set has more information than before.

• Refined Conditional Checks
  We've made some improvements to the way we handle conditions involving asset status and certain fields. We refined how we check conditions, thus boosting the robustness and accuracy of our permission processes.