LPS-30949 Partial revert of 79fd9c85: enabling invited users to edit time

Also:
Revert "LPS-30949 Preventing invited users from changing time from children events"

This reverts commit 8d5dff686665e127ba79e7ea3f844ef879d9d9b3.

Conflicts:
	portlets/calendar-portlet/docroot/edit_calendar_booking.jsp
LPS-30949 Using more concise message as debated with Jim Hinkey
LPS-30949 Using more reasonable dimensions to confirm dialog
LPS-30949 Extracting service calling from user consultation callbacks
LPS-30949 Removing children event instances to avoid duplication on invited calendars
LPS-30949 Moving dialog out from persistence function
LPS-30949 Adding a recurring child event instance to the list of instances to update
LPS-30949 New child calendar booking resulting from "All Following" / "Only this instance" updates now refers to the original parent calendar

Also making finder return a collection since an event can have more than one child booking in one calendar
LPS-30949 Removing broken memoization for confirm dialogs

Also removing spurious call to a "hide()" method
LPS-30949 Extracting persisting methods to CalendarUtil
LPS-30949 Extracting confirmation dialog to function and using it to get user choices in edit window
LPS-30949 The service methods should offer the option of either updating only the current calendar booking or updating all children calendars
LPS-30949 Asking user about updating either only the current booking or all children bookings
LPS-30949 Liferay.CalendarList accepts only one instance of each calendar

This avoids duplication of calendars on the list of invited resources of the booking edit window
when there is more than one child calendar booking
LPS-30949 Making method for children counting public; using it on JavaScript
LPS-30949 Choosing to apply a change on a later instance to all series will not make the event series start at the edited instance
LPS-30949 Avoiding duplication of first instance when editing time of recurring event

If one edits a recurring event by clicking on its first instance and then choose
to salve "All Following", the first instance would be duplicated with the previous
time. This commit solves it.

Also, now the loop does not update the startTimeJCalendar anymore, so multiple, undesired
changes are are not applied to it anymore. It used to result on events from child
calendars having one or more day less than the edited master calendar.
LPS-30949 The value of old start time is taken from last request

Now, if a user updates all events by editing a later instance twice then the events will not be shifted
LPS-30949 Ask user for each necessary confirmation when moving an event to trash

Also, messages were updated so now they say the event is going to be "moved to trash" instead of being "deleted"
LPS-30949 Regenerate