Implementing automatic includes

[RhoSigma-QB64]

Long discussed, finally here :)

• Adapted the forced include mechanism (originally implemented by Fellippe to include the $DEBUG/vWatch stuff) to allow any number of auto-includes before and after the regular program content.
• The system is now also smart enough to see when such a file is loaded directly and then not including it, so it avoids all the duplicate definitions caused by that.
• Added beforefirstline.bi and afterlastline.bm files in internal/support/include, which implement some CONST and helper functions and be helpful in the future for other things. Read the file header, some rules must be followed to avoid conflicts or errors with user code.
• Best way to ensure the rules is to always edit the files in the IDE, which detects these files when loaded and switches into a special mode to enforce the rules.

Also in this PR:

• Implemented human readable syntax entries (idstruct) for user defined SUBs and FUNCTIONs for better reference.
• Used the new auto-includes to implement the _MIN and _MAX functions as new internal keywords to QB64PE, more or less as example how to make it.
• Also implemented EncodeURL$ and DecodeURL$ functions here, which may be used in conjunction with the _OPENCLIENT(HTTP:url) syntax
• We can consider taking the HTTP stuff out of $UNSTABLE now, as this closes #259 in the respective Milestone and it would also make sense for the v4.0.0 release.

You may probably ignore reviewing the internal/source related commits, too many changes to the internals, so I just thought to provide the whole thing for bootstrapping.

[FellippeHeitor]

Just some trivia: The force include mechanism was already there when I adapted it for $debug; Galleon had put it in place for the old Virtual Keyboard subsystem (remember the Android dream?).

[RhoSigma-QB64]

Just some trivia: The force include mechanism was already there when I adapted it for $debug; Galleon had put it in place for the old Virtual Keyboard subsystem (remember the Android dream?).

Aha, didn't know that.

[mkilgore]

Some thoughts on the Http changes:

After seeing this I'm thinking I was wrong about having us encode the URL for the user, I think it would be better to expose your _EncodeUrl$ and _DecodeUrl$ functions as part of the language and leave it up to the user to correctly encode the URL passed to _OpenClient (we would also remove the URL state logic from _EncodeUrl$, it would just encode whatever it is given). The problem is that there's ambiguous cases where only the user would know the correct way to encode the URL (Ex. ?foo=bar&baz). Presumably this same issue is why libcurl doesn't do the encoding automatically either, not sure why that didn't occur to me 🤦

The separate thing is libcurl inclusion. You mentioned in the comments keeping _WhatIsMyIp$ TCP/IP-based to avoid pulling in libcurl, but that won't work if $Unsafe:Http is removed - all networking programs will get libcurl because we don't know how they will use _OpenClient. It's definitely an issue worth considering, I think the only real way to avoid it is to add a new flag to replace the $Unsafe:Http flag (which admittedly is a bit ugly).