🥅 Successfully parse invalid response code data

[nevans]

When the parser encounters a recoverable error in resp-text-code, it now returns InvalidParseData to represent the data that we've skipped over. InvalidParseData can be used for similar recoverable parse errors in the future (for example, many servers respond with invalid BODYSTRUCTURE or incorrectly escaped quoted strings).

The specific example I have encountered the most is when Microsoft's IMAP servers send an invalid COPYUID response code. Although it is invalid for resp-code-copy, it's still a valid resp-text-code because it does match atom [SP 1*<any TEXT-CHAR except "]">].

This creates some minor differences for invalid resp-text-code data:

• <= v0.6.2: raises ResponseParseError (this is a bug).
• == v0.6.3: returns ResponseText with no ResponseCode (also a bug).
• >= v0.6.4: returns ResponseText with code with InvalidParseData.

Although this is a bugfix, it has a minor incompatibility for response handlers which assume that a particular ResponseCode#name always results in the same type of ResponseCode#data.

# This was previously a safe assumption
imap.add_response_handler do |resp|
  if resp in {data: {code: {name: "COPYUID", data: copyuid}}}
    copyuid => Net::IMAP::CopyUIDData
  end
end

# With this change, ResponseCode#data could also be InvalidParseData
imap.add_response_handler do |resp|
  if resp in {data: {code: {name: "COPYUID", data: copyuid}}}
    copyuid => Net::IMAP::CopyUIDData | Net::IMAP::InvalidParseData
  end
end

Prior to v0.6.3, these responses would raise a ResponseParseError and the response handler would not have been called.