Fixed crashing on date formatting helper when value is not actually a date

[snipe]

This just wraps the Carbon method in a try/catch to prevent crashing on bad data, so if the $date value isn't actually valid, we don't crash out completely.

While this shouldn't typically happen since we validate dates before entering them into the database (and we use date/datetime fields for native fields in the system), it is a possible scenario that a custom field could be created as an "ANY" field, data gets added, and then the custom field format gets edited to DATE or DATETIME later. If someone put bad data in the database before then - or if they manually edited the field's value - it will crash with:

DateTime::__construct(): Failed to parse time string (TBV) at position 0 (T): The timezone could not be found in the database (View: /Users/snipe/Sites/snipe-it/snipe-it/resources/views/hardware/view.blade.php)

This will now not crash and will instead return an error that the date is invalid.

While I find it ugly to return a string (instead of false, etc), this method was flat-out crashing as it is now (when there was bad data). A further refractor might be in order down the line, but this at least fixes the immediate problem.

[uberbrady]

This makes a ton of sense - I agree there's a slight wonkitude to returning a string (and a non-internationalized one, at that), but this is still much better than uncaught exceptions all over the place. I think this is going to make our lives easier, and our user's lives easier. Nice work!