Closes #5217

Closes #5197

When using tabs for indentation, the markers would not always align with the actual problem.
The old workaround for JSHint never really worked (only when a line had one tab) and I found a simple option which fixes the issue.
This time I also checked backwards compatibility, which works even fine with the old JSHint version R07.
As a second marker fix, I added an error line check, since JSHint for some reason adds configuration issues in the errors array with line: 0, character: 0. Now, if you pass an invalid option you will get a console error instead of an invisible marker.

As of 1d5c828f the missing js semicolon is a warning and not an error anymore, therefore I added an error elsewhere.

When enabling strict equality checks via `lint: {options: {eqeqeq: true}}`, found problems showed up as errors instead of warnings.
To fix it, the `fixWith()` logic had to be changed since simply adding the phrase to the warnings array would not have worked. This is because both the warnings and errors array matched this exact error and therefore the severity could never be "warning" (errors were checked after warnings).

I didn't include "Missing property name" and "Unmatched " in the new error array since they already are errors with the new logic.
"Stopping, unable to continue" also got removed since it didn't appear anywhere in the current jshint.js.

For now I've implemented everything to not break previous behavior/hinting, except the strict equality hint severity. Although I want to suggest removing the following codes from the new error array (so they can stay warnings):
- W033 (Missing semicolon) - since erroneous missing semicolons have their own code: E058
- W084 (Expected a conditional expression and instead saw an assignment) - since something like `switch (var2 = var1 + 42)` is valid js code, though not recommendable
- maybe W023/24/30/90, since there are many more " and instead saw an" hints that are already errors with their own codes, so I think they should be pretty accurate. Unfortunately I couldn't force these warnings so I couldn't check.

Closes #5187

Closes #5180
Closes #5181

No longer creates a fold spot for both lines of a line-broken
tag.

Closes #5179

Closes #5178

Issue #5177

If you try to autocomplete at line 0, column 0 after previoulsy having edited for example a WHERE clause, the autocompletion triggers with an invalid position, since prevItem is null.
Maybe my fix isn't the best solution, and you could even avoid to enter findTableByAlias enitrely, I don't know.

Show column hints (if a defaultTable is set) above table hints, since
you are far more often in clauses where you need those.

Closes #5174

 * Add common keywords for ML languages
 * Add builtins for OCaml and F#
 * Add Standard ML as ML language

This had been broken since 5.12 due to a change in the behavior
of findMarksAt.

Closes #5171

The CREATE DATABASE command supports LC_CTYPE and LC_COLLATE keywords as
per https://www.postgresql.org/docs/10/static/sql-createdatabase.html.
This commit adds them to the postgres sql mode.

Issue #5148

tl;dr: `text/markdown` since March 2016
---

In March 2016, `text/markdown` was registered as [RFC7763 at IETF](https://tools.ietf.org/html/rfc7763).

Previously, it should have been `text/x-markdown`. The text below describes the situation before March 2016, when RFC7763 was still a draft.

---

There is no official recommendation on [Gruber’s definition](http://daringfireball.net/projects/markdown/), but the topic was discussed quite heavily on the [official mailing-list](http://six.pairlist.net/pipermail/markdown-discuss/2007-June/thread.html#640), and reached the choice of `text/x-markdown`.

This conclusion was [challenged later](http://six.pairlist.net/pipermail/markdown-discuss/2008-February/000960.html), has been confirmed and can be, IMO, considered consensus.

This is the only logical conclusion in the lack of an official mime type: `text/` will provide proper default almost everywhere, `x-` because we're not using an official type, `markdown` and not `gruber.` or whatever because the type is now so common.

There are still [unknowns](http://six.pairlist.net/pipermail/markdown-discuss/2007-June/000652.html) regarding the different “flavors” of Markdown, though. I guess someone should register an official type, which is supposedly [easy](http://tools.ietf.org/html/rfc4288#section-3.4), but I doubt anyone dares do it beyond John Gruber, as he very recently [proved](http://blog.codinghorror.com/standard-markdown-is-now-common-markdown/) his attachment to Markdown.

There is a [draft](https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/) on the IETF for `text/markdown`, but the contents do not seem to describe Markdown at all, so I wouldn't use it until it gets more complete.