Improves WiFiMulti

[SuGlider]

Description of Change

This PR is based on PR #2775 from @Daemach, with some changes.

WiFiMulti has now new methods that improves its ways to connect to a WiFi AP.
It adds a new example to the ESP32 Core called WiFiMultiAdvanced.ino.

An important improvement is that the WiFiMulti run() will mark the failed WiFi APs in order to do not include them in the next run() execution. This avoids that it fails all the time in the very same AP with the highest RSSI. After failing with all possible APs of the list, it will reset the "failed marks" and try again from fresh.

New APIs:

• void setStrictMode(bool bStrict)
  Default is true: It forces to only keep connected or to connect to an AP from the provided WiFiMulti list.
  When bStrict is false, it will keep the last/current connected AP even if not in the WiFiMulti List.

• void setAllowOpenAP(bool bAllowOpenAP)
  Default is false: doesn't add open AP networks to the WiFiMulti list.
  When bAllowOpenAP is true, it will add ANY scanned open open AP to the WiFiMulti list, even if not in the initial user list

• void APlistClean(void)
  Clears the current list of Multi APs and frees the memory

• void setConnectionTestCallbackFunc(ConnectionTestCB_t cbFunc)
  Default is NULL - no validation callback function
  It allows the user to define a callback function [bool cb_func(void)] that will validate the connection to the Internet.
  If the callback returns true, the connection is considered valid and the AP will added to the validated AP list.
  Set the callback to NULL to disable the feature and validate any SSID that is in the list.

Tests scenarios

Using 3 APs, 1 Open AP.
Used the new WiFiMultiAdvanced.ino example to test many combinations in Verbose Mode.

Related links

Closes #2775

[github-actions]

	Warnings
⚠️	Some issues found for the commit messages in this PR: the commit message "feat(wifi): Improves WiFiMulti": summary looks too short the commit message "fix(WiFi): fixes a type in the commentaries": scope/component should be lowercase without whitespace, allowed special characters are _ / . , * - . Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert,test sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).
⚠️	Please consider squashing your 7 commits (simplifying branch history).

👋 Hello SuGlider, we appreciate your contribution to this project!

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests.

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
4. If the change is approved and passes the tests it is merged into the default branch.

Generated by 🚫 dangerJS against d8ba28c

[P-R-O-C-H-Y]

LGTM!

[me-no-dev]

Except the example, LGTM too

[thijstriemstra]

👁️‍🗨️