Add QuickBASIC

[DecimalTurn]

Description

This PR adds QuickBASIC (QB) as a langauge for the .bas extension.

Note that there exists a modern version of QuickBASIC known as QB64 that is still compatible with Classic QB. Since Classic QB and QB64 haven't reached the popularity threshold by their own at the moment, I've kept them combined, but we could separate them in the future if popularity justifies it.

The grammar used is the one for QB64, since it is also compatible with Classic QB.

Checklist:

• I am adding a new language.
  • The extension of the new language is used in hundreds of repositories on GitHub.com.
    • Search results for each extension:
      • Search query (3k+ results)
  • I have included a real-world usage sample for all extensions added in this PR:
    • Sample source(s):
      • QuickBASIC samples:
        • https://github.com/skeeto/scratch/blob/master/sp4/sponge4.bas (Unlicense license)
        • https://github.com/DualBrain/QuickPakPro/blob/main/QB64/FGETRT.BAS (MIT)
        • https://github.com/DualBrain/QuickPakPro/blob/main/QB64/VLONG.BAS (MIT)
      • Extra BASIC samples (to help classifier):
        • https://github.com/yantrabuddhi/bwbasic3/blob/a062bd4a05fb9459d6e8188c4185638ccad04df7/NBS2/P180.BAS (GPL 2)
  • I have included a syntax highlighting grammar: https://github.com/QB64Official/vscode
  • I have added a color
    • Hex value: #008080
    • Rationale: Based on the green at the bottom of the QuickBASIC IDE.
  • I have updated the heuristics to distinguish my language from others using the same extension.

[DecimalTurn]

Related issue: #3216

[lildude]

See inline comment

[lildude]

Please don't do this... you're defining VBA and QuickBasic multiple times in the same heuristic. This indicates your heuristics have scope for improvement. This is also confusing and will lead to issues in future.

/cc @Alhadis for some regex skills.

[DecimalTurn]

As far as I know, there is no way to do what I'm trying to do (for VBA) without having more than one entry per language for the .bas extension. I assumed that it was a fair approach since this also occurs for the .properties extension and the .1in extension. However, I remain open to suggestions if there is a better way.

.properties (INI and Java Properties appear twice each):

linguist/lib/linguist/heuristics.yml

Lines 608 to 621 in f164d13

	- extensions: ['.properties']
	rules:
	- language: INI
	and:
	- named_pattern: key_equals_value
	- pattern: '^[;\[]'
	- language: Java Properties
	and:
	- named_pattern: key_equals_value
	- pattern: '^[#!]'
	- language: INI
	named_pattern: key_equals_value
	- language: Java Properties
	pattern: '^[^#!][^:]*:'

.1in (Roff Manpage appears twice):

linguist/lib/linguist/heuristics.yml

Lines 44 to 55 in f164d13

	- extensions: ['.1in', '.1m', '.1x', '.3in', '.3m', '.3p', '.3pm', '.3qt', '.3x', '.man', '.mdoc']
	rules:
	- language: Roff Manpage
	and:
	- named_pattern: mdoc-date
	- named_pattern: mdoc-title
	- named_pattern: mdoc-heading
	- language: Roff Manpage
	and:
	- named_pattern: man-title
	- named_pattern: man-heading
	- language: Roff

[DecimalTurn]

For the second QuickBASIC entry, I could actually merge it with the first considering that VBA/VB6 uses the PascalCase convention and code that was edited in the VB Editor will never have uppercase capitalization for keywords due case enforcing (as discussed here).

Technically, you could have uppercase keywords if you edit VBA/VB6 code while using another editor and it would be converted seemlessly when added to a VB Project, but I haven't seen any cases of that on GitHub. However, GitHub Search is case-insensitive, so it's hard to check.

[DecimalTurn]

@lildude due to the potential interactions between my 2 other open PRs, would it be OK if I rebase them onto one another such that this one is at the top (while still being separate PRs)? This would be better for testing while this PR is being worked on and it should avoid any conflicts at merge time.