Improve the tolerance of base64Cleaner

[XiaoMouR]

Inspired by python, for this issure

[coveralls]

Coverage remained the same at 86.315% when pulling 8abec6c on leibiao:master into 0edd8bb on jhillyerd:master.

[coveralls]

Coverage remained the same at 86.315% when pulling 8abec6c on leibiao:master into 0edd8bb on jhillyerd:master.

[coveralls]

Coverage remained the same at 86.315% when pulling 8abec6c on leibiao:master into 0edd8bb on jhillyerd:master.

[jhillyerd]

Thanks, I hadn't seen that python table before. I like this idea, but I don't like that we are not capturing any errors to send back to the software using enmime.

From my comment on #46 - It would make sense to add an Errors slice to the base64Cleaner struct, and an errorMalformedBase64 const to errors.go, plus whatever other plumbing is required to surface those errors to the consumer.

Perhaps we can keep the original case ' ', '\t', '\r', '\n': statement, and add '=' to it, allowing all those to be stripped silently. But any other characters returning -1 would trigger an error to be added to the list.

Let me know if you are interested in pursuing this, otherwise I can merge this PR into a feature branch and add the error part myself.

[XiaoMouR]

Maybe we can add a switch that controls the strategy of enmime.For example, if use Strict mode, enmime will generate more errors when meets malformed strings.And use Tolerant mode, enmime will try it best to rebuild the content while only generates some necessary errors.
BTW, it's common to analyze malformed spam in my work.I'd like to see this switch added to enmime. :)

[jhillyerd]

Take a closer look at https://github.com/jhillyerd/enmime/blob/master/error.go#L19

We don't need the flag, as the client can filter on Severe or Name to only examine errors it cares about. Or it can completely ignore the Part/Envelope.Errors slice. In which case it only need to pay attention to the hard Go error returned from ReadEnvelope to know that parsing completely failed.