LPS-49277 Add a method to DLEditFileEntryDisplayContext to delegate the check for DDMStructure visibility to the display context. Also implement it for Google Docs.
LPS-49277 Rename DLFileVersionDisplayContext to
DLViewFileVersionDisplayContext. No logic changes.
LPS-49277 Add a new 'enableFileEntryDrafts' key in DLPortletInstanceSettings (we need it for the next commit)
LPS-49277 Remove some unneeded methods from DLViewFileVersionDisplayContext and add some others to DLEditFileEntryDisplayContext.
LPS-49277 Split DefaultDLFileVersionDisplayContextHelper in two: FileEntryDisplayContextHelper and FileVersionDisplayContextHelper. Then, spread methods from the previous file to the new ones depending on what they operate (file or version).

The motivation for this helpers is having some classes that operate on model objects and can be shared among display contexts. This is a new requirement due to the change of scope in display contexts: when they were created they were associated to a model object, but since the last commits, DCs now represent an UI screen.
LPS-49277 Use the modified helpers to implement the new methods in DCs.
LPS-49277 Finish extracting common DC methods to helpers.
LPS-49277 Reuse
LPS-49277 Remove unused logic
LPS-49277 Remove DLViewFileVersionDisplayContext.getPublishButtonLabel() method since it is associated to edition of file entries, not to viewing of file versions. This will simplify the next commit too.
LPS-49277 Refactor DCs and helpers to make them more consistent, avoid code duplication, and not mix responsibilities.

I'm trying to settle the following patterns:

1) Each helper is a decorator of a business object (one for FileVersion, one for FileEntry, and so on). Presentation logic shared across several contexts must go into these classes whenever they apply only to the business object of the helper. Optionally we can pass arguments if the method needs some other dependency.
2) Each DC is a bridge between the JSP and the presentation logic which is spread among helpers, settings, etc... Normally a DC should not have any logic at all, although some is permitted for migration reasons (remember that before this, everything was in the JSPs).
3) Whenever a decision must be taken consulting several business objects, the DC should get helpers for each of them and combine the outputs. If the combination logic can be shared and it's complex, we should create a new business class/concept to handle such complex logic.
LPS-49277 Keep the original signature
LPS-49277 SF
LPS-49277 this is only used once
LPS-49277 SF
LPS-50321 missing @override
LPS-49277 Rename for clarity
LPS-49277 Since we're not in DDM
LPS-49277 Rename
LPS-49277 Sort