[calendar] refactor: migrate CalendarFetcher to ES6 class and improve error handling (#3959)

1. Convert CalendarFetcher from legacy constructor function pattern to
ES6 class (which simplifies future migration from CommonJS to ES
modules).
2. Implement targeted HTTP error handling with smart retry strategies
for common calendar feed issues:
   - 401/403: Extended retry delay (5× interval, min 30 min)
   - 429: Retry-After header parsing with 15 min fallback
   - 5xx: Exponential backoff (2^count, max 3 retries)
   - 4xx: Extended retry (2× interval, min 15 min)
   - Add serverErrorCount tracking for exponential backoff
- Error messages now include specific HTTP status codes and calculated
retry delays for better debugging and user feedback

Previously, CalendarFetcher did not respond appropriately to HTTP
errors, continuing to hammer endpoints without backoff, potentially
overloading servers and triggering rate limits. This refactoring
implements respectful retry strategies that adapt to server responses
and reduce unnecessary load.

Maybe we could later centralize the HTTP error handling and use it for
weather and newsfeed as well.

The PR was inspired by having worked on the calendar fetcher for
MMM-CalendarExt2, where there was already better error handling.

js/node_helper.js

@@ -113,8 +113,11 @@ NodeHelper.checkFetchError = function (error) {
 	let error_type = "MODULE_ERROR_UNSPECIFIED";
 	if (error.code === "EAI_AGAIN") {
 		error_type = "MODULE_ERROR_NO_CONNECTION";
-	} else if (error.message === "Unauthorized") {
-		error_type = "MODULE_ERROR_UNAUTHORIZED";
+	} else {
+		const message = typeof error.message === "string" ? error.message.toLowerCase() : "";
+		if (message.includes("unauthorized") || message.includes("http 401") || message.includes("http 403")) {
+			error_type = "MODULE_ERROR_UNAUTHORIZED";
+		}
 	}
 	return error_type;
 };