Bug fixes and minor re-factoring inside DLNAResource.java

I'm a developing a personal iOS app to serve as a control point for my Sony TV (renderer) and my UMS. As you may know Sony TVs are very strict as far as DLNA is concerned and I found and fixed a couple of bugs which allow my project to be possible.

Please ignore the first 2 commits, the first one was from a previous pull request which was copied over in a different commit by @SubJunk and the second is just a merge to catch up my fork.

The commit messages should speak for themselves. Please don't hesitate to ask me anything and if you're not satisfied, I don't mind reworking:

1) [LOW PRIORITY] 075f902 **Allow the code path which creates the DLNA.ORG_PN string to be entered if the renderer is configured to use accurate DLNA.ORG_PN.** The renderer configuration file for my BraviaEX had the "AccurateDLNAOrgPN" defined but not "DLNAOrgPN" and because of this, a necessary code path to create required DLNA header flags was not taken. I took these two options to mean that only one or the other should be defined in the configuration files, so fixing the code the way I did seemed like the logical thing to do. If my assumption is wrong then I could easily just add the "DLNAOrgPN" to my renderer's config and be done with it.

2) [HIGH PRIORITY] e28ef8e **Allow the DLNA.org content features header value to be set correctly when the method which sets necessary instance variables had not been called yet.** Basically there's a method called getDidlString() which although it's a getter, oddly sets instance variables which are needed to ensure getDlnaContentFeatures() returns the correct header strings. So I had to call it before the return. Having a getter set instance variables is certainly a code smell to me, so I refactored this part in the next commit (3)

3) [PART OF 2] 82f48e0 **Refactor the DLNA.ORG_OP and DLNA.ORG_PN flag instance variables into methods as they require a renderer configuration to be generated.**