Enable user setting for absolute dates

What does this MR do?

Enable user setting for absolute dates

A long while ago we have created a feature flag :user_time_settings which introduced one feature flag for three settings:

1. User setting for relative/absolute date formatting
2. User setting for 24-hour format
3. User setting for setting time zones on profiles

This commit untangles this a little bit and allows users to change from our default (relative date formatting) to absolute date formatting with the help of the Intl.DateTimeFormat API.

From a frontend perspective we luckily do (almost all) timeago.js operations for formatting relative dates in one utility file, so it is really easy to hook into that and render absolute dates.

The only thing we need to do from a backend perspective: We need to expose the already existing user setting time_display_relative in window.gon so that the frontend can use it.

So what did we do in this commit:

1. Update Preferences page pulling Time preferences into a new section outside of the feature flag and expose the time_display_relative user setting.
2. Keep the time_format_in_24h user setting behind the feature flag, because we are not using it right now. And to be honest, we can likely remove it (see further down for reasoning)
3. Expose the user setting on Gon as gon.time_display_relative
4. Based on gon.time_display_relative we either render relative or absolute dates.
5. The date format chosen looks like May 18, 2021, 3:57 PM for the default English settings. (not showing time zones or seconds)

What didn't we do in this commit:

1. We could and should teach createDateTimeFormat to respect the browser settings and fall back on the language settings. If we really want to give the user control, we could introduce another user setting to define their wanted locale, but this is what browser settings are for. If e.g. a user has en_GB as their browser locale dates would render in 24h format automatically, rendering the time_format_in_24h setting obsolete.
2. We should adjust our current formatDate API (still used for the tooltip and showing time zone and seconds) to utilize Intl.DateTimeFormat as well. This would unify the implementation, make it more consistent and likely faster, smaller. This would also solve loads of issues around weirdly formatted dates
3. We didn't adjust the timeFor function which is used for due dates and such.
4. We didn't fix the one direct import of timeago.
5. Implement a instance-wide setting like the Start of the Week.

The only real risks here are:

1. Somewhere where we really need relative dates might show absolute dates. (I cannot contrive an example)
2. Somewhere layout breaks with absolute dates.

I don't think these risks compare to the benefit that this brings to users that wanted (or needed this) for a long time. If something really breaks, the user could always disable it again.

Screenshots or Screencasts (strongly suggested)

What	Relative	Absolute
Settings
Projects Dashboard
Issues list
Issue detail

Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team