Allow timestamp in due_date

Description

Change the way due_dates are handled to allow ISO 8601 date / time strings

Proposal

Allow date AND time when setting a due_date on an issue or milestone. For the front-end, this could be a time / date dropdown. For the API, this would be simply allowing an ISO 8601 string, like you can with created_at

Links / references

Documentation blurb

# Setting a due date 
When creating or editing an issue, you can see the due date and time fields from where a calendar will appear to help you choose the date  and time you want. To remove them, select the text and delete it.

A quicker way to set a due date is via the issue sidebar. Simply expand the sidebar and select Edit to pick a due date and optional time or remove the existing ones. Changes are saved immediately.

Overview

When creating an issue, you might want to set a specific time for the issue to be due by. Right now you can set a date, but not a time. Other date-related fields (updated_at, created_at) allow both, but due_date doesn't.

Having both would be useful for people who want to set due dates around working hours. For example you might want to have an issue due by close of business next Friday.

Use cases

The reason I'm suggesting this, is that management asked that a set of issues relating to a project be fixed by close of business on a particular day. At that same time, non-GitLab related information (graphical assets) were also due. When they looked in the issue tracker, they saw the issues as being still open despite it being past 5pm.

Other use cases could be:

• To line up dates and times with other events (e.g. close of business, submission dates for website content, to mark the end of a discussion about a new feature etc.)
• Use due_date in API-based mashups (e.g. a project I'm working on that uses GitLab as a helpdesk

Feature checklist

Make sure these are completed before closing the issue, with a link to the relevant commit.

• Feature assurance
• Documentation
• Added to features.yml