Avoid confusion about TripSummary

[pvgrumbkow]

Removed AcceptDeferredDelivery from TripPolicyFilterGroup. Instead added TripSummaryOnly into TripContentFilterGroup as the parameter to control whether complete trips or only trip summaries shall be delivered. There is no relation to a deferred delivery anymore.
Removed IncludeLegs from MultiPointTripContentFilterGroup, as legs are mandatory within trip results. Removed MultiPointTripContentFilterGroup, as there is no need have different content filters for MultiPointTrip or Trip respectively.

[sgrossberndt]

In general I think this change is a good idea, as it simplifies request handling, but it was purposefully added:

Full trip information is sent actively by the server to the Address stated in RequestorEndpointGroup.

This option was not part of TRIAS and has been added to OJP in the initial release - do you know by whom this feature was requested/used?

This once again is a breaking change which must be thoroughly documented.

The documentation in https://github.com/VDVde/OJP/blob/ResponseContextInRequestSupport/OJP_Trips.xsd#L248 needs to be updated too:

				<xs:element name="TripSummary" type="TripSummaryStructure">
					<xs:annotation>
						<xs:documentation>Summary on trip. Only if requestor accepts deferrred delivery of trip details.</xs:documentation>
					</xs:annotation>
				</xs:element>

[pvgrumbkow]

Actually, I don't know the detailed reasons for this design decision. However, I assume, that something similar to the once existing DELFI partial connection service was planned (which computed something similar to a TripSummary), but with the mechanisms of SIRI messages. Such a "TripSummary only" service is not part of TRIAS and had to be invented for OJP. But I assume, that the usage of deferred delivery for this was not intension but chance.
Even if somebody is really interested in using the mechanism "deferred delivery" (without choosing the content), this would have to be modeled differently IMHO. Choosing content or functionality should not be mixed with choosing transport mechanism.
Therefore I would still prefer to simply remove AcceptDeferredDelivery. If there is in future really a need for asynchronous Trip requests, we can still add it.
I will upload a new version with changed comment for TripSummary.