Add setting for first day of the week

What does this MR do?

Closes #2105 (closed) Closes #19282 (closed)

This MR adds settings to configure which is the first day of the week (Sunday or Monday). The setting is then used in datepickers and the contribution calendar (see screenshots).

In detail, two new settings were added:

• a global first_day_of_week application setting which is 0 (Sunday) by default and which can be changed in the admin interface
• a first_day_of_week user setting which can be changed in the user preferences view

Both of these settings are located in a new section called "Localization". This section could also be used for the "Language" or the "Timezone" settings (see #35638 (closed) and #37900 (moved)).

Screenshots

Migration Output

== 20181027114222 AddFirstDayOfWeekToUserPreferences: migrating ===============
-- add_column(:user_preferences, :first_day_of_week, :integer)
   -> 0.0007s
== 20181027114222 AddFirstDayOfWeekToUserPreferences: migrated (0.0007s) ======

== 20181028120717 AddFirstDayOfWeekToApplicationSettings: migrating ====
-- transaction_open?()
   -> 0.0000s
-- execute("SET statement_timeout TO 0")
   -> 0.0004s
-- transaction()
-- add_column(:application_settings, :first_day_of_week, :integer, {:default=>nil})
   -> 0.0010s
-- change_column_default(:application_settings, :first_day_of_week, 0)
   -> 0.0091s
   -> 0.0121s
-- transaction_open?()
   -> 0.0000s
-- exec_query("SELECT COUNT(*) AS count FROM \"application_settings\"")
   -> 0.0011s
-- change_column_null(:application_settings, :first_day_of_week, false)
   -> 0.0014s
-- execute("RESET ALL")
   -> 0.0003s
== 20181028120717 AddFirstDayOfWeekToApplicationSettings: migrated (0.0159s) 

Database checklist

• Conforms to the database guides

When adding migrations:

• Updated db/schema.rb
• Added a down method so the migration can be reverted
• Added the output of the migration(s) to the MR body
• Added tests for the migration in spec/migrations if necessary (e.g. when migrating data)

When adding or modifying queries to improve performance:

• Included data that shows the performance improvement, preferably in the form of a benchmark
• Included the output of EXPLAIN (ANALYZE, BUFFERS) of the relevant queries

When adding foreign keys to existing tables:

• Included a migration to remove orphaned rows in the source table before adding the foreign key
• Removed any instances of dependent: ... that may no longer be necessary

When adding tables:

• Ordered columns based on the Ordering Table Columns guidelines
• Added foreign keys to any columns pointing to data in other tables
• Added indexes for fields that are used in statements such as WHERE, ORDER BY, GROUP BY, and JOINs

When removing columns, tables, indexes or other structures:

• Removed these in a post-deployment migration
• Made sure the application no longer uses (or ignores) these structures

General checklist

• Changelog entry added, if necessary
• Documentation created/updated
• Tests added for this feature/bug
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides