ICU-22991 Remove unnecessary overload in Calendar

[FrankYFTang]

1. Remove unnecessary call to setTimeInMillis(getNow(), success); in constructor except in GregorianCalendar because allother calendar are not public class and are created through the Calendar::createInstance() method and code in that method already call setTimeInMillis(getNow(), success);

Notice the Calendar API documentation states

"Like other locale-sensitive classes, Calendar provides a static method, createInstance, for getting a generally useful object of this type. Calendar's createInstance method returns the appropriate Calendar subclass whose time fields have been initialized with the current date and time:

Calendar *rightNow = Calendar::createInstance(errCode);
"

and this is guaranteed in the code

Calendar* U_EXPORT2
Calendar::createInstance(TimeZone* zone, const Locale& aLocale, UErrorCode& success)
{
...
    // Now, reset calendar to default state:
    c->adoptTimeZone(zonePtr.orphan()); //  Set the correct time zone
    c->setTimeInMillis(getNow(), success); // let the new calendar have the current time.
    return c;
}

icu/icu4c/source/i18n/calendar.cpp

Line 985 in b0ae845

c->setTimeInMillis(getNow(), success); // let the new calendar have the current time.

And there are no need for all the setTimeInMillis(getNow(), success); inside each constructor

2. Remove overloading of operator= in Calendar since these implementation currently are the same as compiler generated assignment operator
3. Simplified the GregorianCalendar constructor by chaining the calls
4. add "static const int32_t kDefaultCutoverYear = 1582;" inside GregorianCalendar to make it clear

Checklist

• Required: Issue filed: ICU-22991
• Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
• Required: The PR description must include the link to the Jira Issue, for example by completing the URL in the first checklist item
• Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-1234 Fix xyz"
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable