Add line numbers to xml validation errors

[csc-jm]

Description

Before this PR, validation error reasons when validating an XML file would be something:
Unexpected child with tag 'BAD_ELEMENT' at position 2.
This PR makes those more understandable so they'd instead come out as:
Unexpected child with tag 'BAD_ELEMENT' at line 34.

Also the changes made here enable the validator to find all the errors from the file at once.

Related issues

Fixes #91

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update (this needs a follow up PR)

Changes Made

• changed the xml validator to add line numbers to error messages
• updated existing unit tests

Testing

• Unit Tests

Mentions

[csc-jm]

When researching possibilities for this, I thought I had found a simple solution with xmlschema.assertValid() as shown here where you could get something like this:

xmlschema.assertValid(doc2)
Traceback (most recent call last):
  ...
lxml.etree.DocumentInvalid: Element 'c': This element is not expected. Expected is ( b )., line 1

However, after implementing this vulture complained that using lxml.etree is not safe anymore. It would have also required schemas to be loaded in a different way, which would have resulted in a bigger refactor. So the solution in this PR is best I could come up with without refactoring things too much.

[csc-felipe]

Good work putting the line numbers there ^^ Much appreciated.

The API error responses are quite well standardized (since #433), although the validation errors were not following it. The detail field is always a str, following the JSON Problem Details specification https://www.rfc-editor.org/rfc/rfc7807. It would be nice to stick with it.

Would it make sense to change it in this PR, as you are already proposing a change to the validation error message?

[csc-jm]

Ok, I altered the new functionality slightly so it collects the error messages and concatenates them in the same string of the reason key separated by an endline. It's not ideal but things will hopefully be fixed as the whole response will need some reformatting from its prior state. I opened the issue #641 for a follow up.

[csc-felipe]

lgtm