"dddd" and "ddd" tokens no longer support different capitalisations from 0.15.8

[NestorTejero]

Issue Description

From the 0.15.8 release, the dddd and ddd tokens are not case insensitive. For this, only proper capitalisations work: 'Monday' in English, 'lunes' in Spanish and so on. Any different capitalisation breaks on DateTimeParser._parse_token().

For example this "MONDAY" does not work (it does with "Monday"):

f = 'dddd, MMMM DD, YYYY'
date_en = 'MONDAY, June 24, 2019'
arrow.get(date_en, f)

And produces the following error:

Traceback (most recent call last):
File "mytest.py", line 5, in <module>
print(arrow.get(date_en, f))
File "/bla/env/lib/python3.7/site-packages/arrow/api.py", line 21, in get
return _factory.get(*args, **kwargs)
File "/bla/env/lib/python3.7/site-packages/arrow/factory.py", line 243, in get
dt = parser.DateTimeParser(locale).parse(args[0], args[1])
File "/bla/env/lib/python3.7/site-packages/arrow/parser.py", line 238, in parse
self._parse_token(token, value, parts)
File "/bla/env/lib/python3.7/site-packages/arrow/parser.py", line 346, in _parse_token
parts["day_of_week"] = self.locale.day_names.index(value) - 1
ValueError: 'MONDAY' is not in list

Same with "Lunes" instead of "lunes":

f = 'dddd, D MMMM YYYY - H:ma'
date = 'Lunes, 24 Junio 2019 - 3:39am'
print(arrow.get(date, f, locale='es'))

It works well when deleting the following lines, introduced in the PR !823:

elif token == "dddd":
     parts["day_of_week"] = self.locale.day_names.index(value) - 1

 elif token == "ddd":
     parts["day_of_week"] = self.locale.day_abbreviations.index(value) - 1

I wonder if this is a feature or a bug. To me, it is a bug, since other non-conventional capitalisations work for other tokens, such as "JUNE" instead of "June" in this example:

f = 'dddd, MMMM DD, YYYY'
date_en = 'Monday, JUNE 24, 2019'
print(arrow.get(date_en, f))

System Info

• 🖥 OS name and version: macOS 10.14.4
• 🐍 Python version: Python 3.7.1
• 🏹 Arrow version: 0.15.8 and up

[jadchaar]

Ah yes, this is indeed a bug. We originally handled this fully in regular expressions, but to fix a day of week bug we needed to resort to this technique instead. I just posted a PR to fix this by normalizing the strings before checking.