[2.0.x] Support TMC2660

[teemuatlut]

Add support for Trinamic TMC2660. Basically this means the Panucatt BSD2660 drivers.
Not every feature is written yet but I'd like to get the basic support going for a broader audience.
The drivers do not have an EN pin so the function is implemented in software through SPI, very similar to how TMC26x is not at the moment. The TMC2660 is based on 26x after all.
This functionality can/will be expanded to other drivers as well and all (newer) TMC drivers will be supported. This will also allow for manufacturers and board designers to completely leave out the EN lines on MCUs that may not have many pins available.

---

Touch up on some of the issues from #11943

• M122 S[1, 0] now requires both MONITOR_DRIVER_STATUS and TMC_DEBUG.

---

Here's a general plan for the rest of the year.
Ticked boxes mark the changes introduced in this PR and the ones that have already been merged in.

• Move to new universal TMCStepper library
• Implement inherited Marlin TMC classes
• Support TMC2660
• Support TMC5160
• Add sanity checking for driver errors
• Greatly reduce communication attempts for monitoring
• Improve TMC error verbosity with better error messages
• Add communication checking on boot
• Add the ability to change chopper timings (spreadCycle)
• Tweak default chopper settings for quieter spreadCycle operation
• Support Trinamic coolStep technology
• Improve M122 with fetching raw register data
• Add TMC section to the LCD
• Support TMC5130
• Support TMC2224
• Add SOFTWARE_ENABLE for all smart drivers (Request from Panucatt)

[CAP1Sup]

The file names have to be shortened. I have fought with Marlin 2.0 for 2-3 days now, only to find that the path didn't exist to one of the files due to the file name being too long. This was very frustrating, and I think that the filenames, specifically in this library, need to be shortened.

[teemuatlut]

Use PlatformIO or Arduino IDE 1.9.0 or change the build.path for older IDE versions.

[alexxy]

I tested this change. Interesting that drivers constantly reports overtemperature

[robustini]

Please merge this fix, thanks!

[thinkyhead]

I see we have a few instances of HAS_DRIVER(TMC2130) || HAS_DRIVER(TMC2660). What is it that these two drivers have in common? Perhaps we should add a conditional that groups them according to their common special property, which I'm assuming would be "TMC_HAS_SPI." These two are also currently grouped with the conditional HAS_STALLGUARD, so that should be used wherever stallguard is relevant.

[teemuatlut]

SPI and stallGuard. I didn't want to create a new collective macro when it was just two drivers and there are only three instances where it would apply.
It'll become more relevant when we add TMC5160, so we can add it now or later.

[thinkyhead]

It'll become more relevant when we add TMC5160, so we can add it now or later.

I figure it's good to be expressive and make it so that we only have to change it in one place as new drivers are introduced, even though we might end up adding to the "conditional overload." But then, I suppose we crossed that bridge a while ago.

[thinkyhead]

I tested this change. Interesting that drivers constantly reports overtemperature

@teemuatlut — Is this something that needs to be looked into before this can be merged?

[teemuatlut]

I did a diff between this PR and the one @alexxy has been using and there aren't any significant changes.
But I did rewrite parts of the monitoring feature that are not part of this PR. They might be masking some issues possibly.

[thinkyhead]

I've got to take my recently-fixed-not-fixed car into the shop to find out what the previous shop did wrong. I'll be back in an hour or so.