This PR suggests a different behavior for parsing cookie expiry dates.

Two changes were made:

1. Add Curl_parse_expiry which is used to parse HTTP cookie expiry dates. The only difference to curl_getdate is that it does not return an error in case of PARSEDATE_LATER. This means that cookies with expiry later than 2038 do not get parsed as session cookies any more, but as cookies with the latest possible expiry timestamp.
   Reason: I use curl in a project where the server returns cookies with expiry dates of 2087 and later (for whatever reason). Curl treating these as session cookies and ignoring them upon restart caused big issues and seems counter-intuitive to me.
2. Change the behavior of parsedate to not return TIME_T_MAX when we are unsure if we can represent the given date in time_t. Instead, return the timestamp for 01.01.2038, 00:00 in the timezone specified in the date string.
   Reason: This ensures that we never return a later timestamp than specified in the datestring, so the returncode PARSEDATE_LATER does not lie. Note that this does not change the behavior of curl_getdate, which returns an error if the returncode is not PARSEDATE_OK.

Note: I added Curl_parse_expiry to avoid a change to the behavior of the public interface by changing curl_getdate.

ToDo:

• Make parsedate consistent by replacing this code:

  if(yearnum < 1903) {
      *output = TIME_T_MIN;
      return PARSEDATE_SOONER;
  }
  

  With an equivalent mechanic to that used in overflow.
• Make Curl_parse_expiry deal with PARSEDATE_SOONER the same way it deals with PARSEDATE_LATER for consistency
• Add unit tests for this behavior