Code restructuring and support for esp32

[michaelzs85]

• Restructured the classes
  • wifi connection handling moved to CTBotWifiSetup
    • This changes how the library is used
    • separates wifi connection from telegram-bot functionality
  • ssl-connection handling moved to CTBotSecureConnection
    • This changes nothing from a user-point-of-view but separates some of the platform specific code from the otherwise platform-independent telegram-bot functionality.
• Added support for ESP32
  • By default the code is compiled for esp8266
  • Compilation for esp32 can be activated by either
    • Changing the #define CTBOT_BOARD 8266 in CTBotDefines.h to #define CTBOT_BOARD 32
    • or using -DCTBOT_BOARD=32while compiling
  • Known Problem: I could not get the fingerprint verification to work for ESP32
• Adapted travis.yml
  • All the examples are now compiled for both esp8266 and esp32

[michaelzs85]

Hey @shurillu, I would really like some feedback on the pull-request. If the whole pull-request is to big I will try to split it into smaller parts - let me know!

[shurillu]

Hello michaelzs85,
thank you for the great work that you are doing.
Sadly those days are very busy and I didn't find the time to check the pull request.
So please give me some more time to review the pull request.
A thing that I want to modify is keep the backward compatibility (maybe with stub member function).
Stefano

[shurillu]

Hello michaelz85,
finally I found the time to examine all your excellent work, well done.
I made a new branch named ESP32_Support. I made some changes:

• No need to define platform (ESP8266/ESP32); now it check the selected board in Arduino IDE (or similar)
• Created some stub member functions for backward compatibility. I guess some member functions like useDNS, setStatusPin, setFingerprint (all based on CTBotSecureConnection) must be exist in CTBot class.

Speaking about the use of fingerprint in ESP32 platform. If I remember well, the fingerprint is a trick used in ESP8266 platform to check the https connection because the ESP8266 low resources can't do the "standard https job".
ESP32 platform have plenty resources (compared to ESP8266) so I guess this platform don't need it.

So, thank you very much for all you did (I planned several years ago to support ESP32 and now, with your work it comes possible!) and if you want to continue to help me, you are welcome!!

Stefano

P.S.: if you want, I'll put your name in the special thanks section.