LPS-33626 Apply portlet-data.xml null check in PortletImporter so PortletDataHandlers don't have to
LPS-33626 Logic in previous commit can be applied to individual portlet data handlers to save on code, but note that this now changes the logic so that if there is no portlet data, we no longer import permissions. This was from Mate's changes in:

https://github.com/juliocamarero/liferay-portal/commit/f84b344cc7c423903ea84039c96c84283837002f

for WikiDisplayPortletDataHandler lines 132. I didn't introduce this logic change. I'm simply trusting that Mate on this and am merging his logic in.
LPS-33626 See notes from previous commit
LPS-33626 We never use the PortletDataContext to both export and import. A new instance of PortletDataContext is always created. So I think it's good to keep the distinction between the existing method PortletDataContext#addExportRootElement and PortletDataContext#getImportDataRootElement. For the former, we are creating a new document. For the latter, we are setting it based on "data". This 100% preserves backwards compatibility for LARs that do NOT use the XML format. Plugin developers may be using JSON. So only when "if (Validator.isXml(data)) {" is true do we set this. Developers can still parse "data" and grab their own document if they want, but this is no longer needed.
LPS-33626 Apply as needed. See previous commit.
LPS-33626 I want to add the feature of getting the export root element without breaking compatibility where we require ppl to reimplement doExportData (from returning a String to a void) and doImportData (removing the "String data" parameter). This requires me to change the method BasePortletDataHandler#addExportRootElement but that's OK because this method was just recently added. This way, portlet data handlers that "upgrade" get new features. Those that don't will still work but getExportDataRootElement will always return null.
LPS-33626 Apply