Added case-insensitive matches for FreeBasic.

[XusinboyBekchanov]

Description

Added case-insensitive matches for FreeBasic heuristics.

Checklist:

• I am fixing a misclassified language (FreeBasic)

  • I have included a new sample for the misclassified language:
    • Sample source(s):
      • [URL to each sample source, if applicable]
    • Sample license(s):
  • I have included a change to the heuristics to distinguish my language from others using the same extension.

• I am changing the source of a syntax highlighting grammar

  • Old: [URL to grammar repo]
  • New: [URL to grammar repo]

• I am updating a grammar submodule

• I am adding new or changing current functionality

  • I have added or updated the tests for the new or changed functionality.

• I am changing the color associated with a language

  • I have obtained agreement from the wider language community on this color change.
    • [URL to public discussion]
    • [Optional: URL to official branding guidelines for the language]

[DecimalTurn]

After looking a little more into it, I'm not sure if it's a good idea to make the heuristics case-insensitive for FreeBasic mainly because when I look at FreeBasic code on GitHub, I see that the use of lowercase is prevalent and I actually found no use of uppercase in the first five pages of results when looking at the highlighted keywords.

Do you have any examples of FreeBasic repos or files missclassified because they were using a different casing convention than the norm?

[XusinboyBekchanov]

Do you have any examples of FreeBasic repos or files missclassified because they were using a different casing convention than the norm?

For example, here is a capital letter:
https://github.com/bob-the-hamster/ohrrpgce/blob/f8cb11c86de7eb1c9c32ae60bb7bd40f131ab97a/miditest.bas

[DecimalTurn]

For example, here is a capital letter:
bob-the-hamster/ohrrpgce@f8cb11c/miditest.bas

I see that this file still makes use of lowercase #include, so the lowercase heuristic would still work.

However, after looking further, I've found the following file:
https://github.com/doranchak/azdecrypt/blob/a9dbde3adc451c1aaccb4b4339f81e1ab5dafc0d/FreeBASIC-1.09.0-winlibs-gcc-9.3.0/examples/GUI/GTK%2B/FB_Calc/FB_Calc.bas#L3

It does only include the use of #INCLUDE and is indentified by Linguist as v7.25 as VBA, so I guess this would be a good case to justify the use of case-insensitive matches.

In that case, I'm in favor of this change even if it won't make a big difference since this won't interfere with other languages currently supported in Linguist.

[Alhadis]

While we're here, we might as well harden these heuristics to deal with files that aren't terminated by a trailing newline (something that's more common on Windows). For example:

regex = /^[ \t]*#(?i)(?:define|endif|endmacro|ifn?def|include|lang|macro)\s/
"Foo\nBar\n#endif\n" =~ regex # => 8
"Foo\nBar\n#endif"   =~ regex # => nil

[lildude]

LGTM. Thanks.

Note: this PR will not be merged until close to when the next release is made. See here for more details.