text: Title: List index out of range in validation.py
  Body: I just wanna apologize beforehand if this issue is a bit incoherent.
  I'm not yet 100% sure what is happening or exactly how to reproduce it but at least I've seen it happen so I'll try to just explain that instead.
  
  ### Expected Behavior
  No exception happening
  
  ### Actual Behavior
  
  I've gotten this stacktrace (but only sometimes)
  
  ```pytb
  [2019-05-28 09:18:24,962] ERROR in patch: list index out of range
  Traceback (most recent call last):
    File "/usr/local/lib/python3.7/site-packages/eve/methods/patch.py", line 179, in patch_internal
      updates, object_id, original, normalize_document
    File "/usr/local/lib/python3.7/site-packages/eve/validation.py", line 44, in validate_update
      document, update=True, normalize=normalize_document
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 990, in validate
      self.__normalize_mapping(self.document, self.schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 671, in __normalize_mapping
      self.__normalize_containers(mapping, schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 757, in __normalize_containers
      self.__normalize_sequence_per_schema(field, mapping, schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 826, in __normalize_sequence_per_schema
      result = validator.normalized(document, always_return_document=True)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 646, in normalized
      self.__normalize_mapping(self.document, self.schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 671, in __normalize_mapping
      self.__normalize_containers(mapping, schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 748, in __normalize_containers
      self.__normalize_mapping_per_schema(field, mapping, schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 812, in __normalize_mapping_per_schema
      result_value = validator.normalized(mapping[field], always_return_document=True)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 646, in normalized
      self.__normalize_mapping(self.document, self.schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 669, in __normalize_mapping
      self.__normalize_default_fields(mapping, schema)
    File "/usr/local/lib/python3.7/site-packages/cerberus/validator.py", line 922, in __normalize_default_fields
      self._normalize_default(mapping, schema, field)
    File "/usr/local/lib/python3.7/site-packages/eve/validation.py", line 72, in _normalize_default
      challenge = challenge[sub_field]
  IndexError: list index out of range
  ```
  
  I have been digging through Eve code and added a few prints in validation.py trying to figure out what is going on and am pretty sure something might be confused around how Eve handles the persisted_document field in validation.py when I'm patching a document (in a maybe specific way).
  
  What I have in my schema is a field that is a list of dictionaries.
  - First POST added one item to this list, so far all is good.
  - Next PATCH when I try to update my list to have two things in it instead the above exception happens.
  
  My theory here is that somewhere in validation (normalization) logic Eve gets the keys from the new data (keys for items 0 and 1 in list in request payload for the PATCH request) but somehow it's trying to read data from the persisted_document (which by this time, in the middle of the PATCH request is still only one item long)
  
  As I explained above, I have added prints in validation.py and seen that the "challenge" object on line 72 is a list of one item instead of two, I also see in the code that challenge is initialized from whatever is in persisted_document.
  
  I'm not sure if I understand Eve code well enough (yet) but shouldn't this code be dealing with the document from the request instead of the persisted one?