DS-1745: DSpace should no longer assign "dc.date.issued=[today]" when date field is missing

[tdonohue]

This PR makes several changes to the logic around how DSpace assigns "dc.date.issued":

1. DSpace no longer auto-assigns a "dc.date.issued=[today]" when missing (except as described below)
2. However, when "Initial Questions" are enabled from the UI, DSpace will still assume "dc.date.issued=[today]" when a user says a work is "unpublished". This allows some form of backwards compatibility. Institutions who have a lot of gray literature in DSpace can enable "Initial Questions" for one or more Collections to have DSpace auto-assign issued dates again. (Please note that "Initial Questions" are disabled by default in 4.0, see DS-1655)
3. Also adds a new option (for SWORD or Bulk Ingest tools, etc) to pass in the literal value dc.date.issued="today" to tell DSpace to set 'dc.date.issued=dc.date.accessioned". This means that you can now decide (in your import metadata) whether you want DSpace to auto-assign issued dates when performing a bulk import.
4. Added new ItemInstall Unit Tests to support this new logic

Finally, I've tested this for all these scenarios:

• Issued date is not specified - Item will still be accepted into DSpace but appears last in "Browse by Issue Date"
• Issued date is literal "today" - DSpace will auto-assign today's date
• Issued date is set via UI (no initial questions) - User is required to fill out an Issued Date
• Issued date is not set via UI (initial questions enabled + "unpublished") - DSpace will still auto-assign today's date (for backwards compatibility)

This logic all seems to be working right. I'd recommend adding this to 4.0/master immediately, assuming no immediate objections.

[tdonohue]

This was reviewed & approved by @mwoodiupui and @hardyoyo (in #dspace IRC) . As mentioned, I've tested this rather thoroughly today as well. Merging for 4.0