Ensure special characters in manifest filepaths are urlencoded

[whikloj]

Resolves #33

This change:

• Checks the payload manifests and fetch files of loaded Bags for any url encoded characters other than %0D, %0A and %25 and fails validation if it finds one. It also fails if it finds an unencoded newline or carriage return (though this really should never happen)
• Correctly urlencodes these characters in payload manifests and fetch files written out by this library

[whikloj]

@pwinckles not sure if you had a specific test that you had been running that you'd like to retry with this PR. I added some tests but always appreciate more eyes.

[pwinckles]

I didn't have any specific tests. I was just eyeballing the libraries to see what they were doing.

Your changes seem good to me.

[pwinckles]

It's unclear to me what fgets considers a newline, but if you're reading the file line by line as defined by the spec where CR, LF, or CRLF are line endings, then it shouldn't be possible for the filepath to contain a CR or LF at this point.

The encoding check is technically correct. However, it does make it so the code would reject bags created by libraries that haven't be updated to encode paths correctly. I don't know if you're interested in accepting those bags or not though.

[whikloj]

Yeah I struggled with this, mostly because I don't use PHP on Windows and so I am biased towards LF as newline characters. Looking at it now, I'm not handling CR line endings properly. I'll make a new ticket for that.

[whikloj]

#36