Support DN to string conversion

[asambeka]

While interacting with LDAP many scenarios require an parsed DN to be reconstructed in a string form after manipulation. E.g. DN structure could be modified to add child node. We need String method to provide the conversion from DN structure to string form.
File affected: dn.go, dn_test.go
Assumptions: Parsing and DN structure population is escape aware
Specs: Follow the DN syntax, avoid unnecessary spaces (e.g. before/after = or + or ,)

[vetinari]

Does this help: https://github.com/vetinari/go-ldapdn ?

[asambeka]

@vetinari I have already submitted this pull for the issue: #155

[asambeka]

@liggitt Please review and approve #155

[johnweldon]

@asambeka I think #104 addresses this at a more general level. Can you confirm that #104 does everything that #155 does, and a bit more?

[asambeka]

I just gave quick look at both:

1. Add String() methods to DN and its subtypes #104 adds DN String() and RDN String() while Support DN to string conversion #154 #155 is doing DN String() only {Gap: RDN String() needs to be added to Support DN to string conversion #154 #155 it is small change, subset of DN String(), let me know if this needs to be added}
2. Add String() methods to DN and its subtypes #104 escaping seems manual and last time I used (was while back) did not work for me. We might need to review escaping and test. I did testing on Support DN to string conversion #154 #155 the escaping is generic and compact. {Gap: Escaping needs to be revisited in Support DN to string conversion #154 #155}.
   I am okay with any 1) or 2). If we are going with 2), I'd prefer if we revisit escaping.

[asambeka]

@johnweldon I have added RelativeDN String() implementation #155

[asambeka]

I have already updated pull comments. To summarize #104 should not include String() rather NormalizedString(), as the function is mutating (case and order change) and not preserving DN representation. String() representation should be immutable representation of DN object. NormalizedString() should follow DN Matching Rule semantics as baseline + features for readability/consistency.