Feature Request: Refactor SPI to allow alternative implementations (e.g., Software SPI)

### The problem
Currently, the core SPIClass is a concrete implementation tied directly to the hardware SPI peripheral (HSPI).

Libraries included in this repository, such as ESP8266AVRISP, are hard-coded to use the global SPI instance. For example, ESP8266AVRISP.cpp directly calls SPI.begin() and SPI.transfer().

This creates a problem: it's impossible to use ESP8266AVRISP (or other similarly-coded libraries) if the hardware SPI pins (GPIO 12, 13, 14) are already in use by another device. It also prevents the use of a "bit-bang" (software) SPI implementation on arbitrary pins.

My goal is to add a Software SPI implementation and be able to use it with the ESP8266AVRISP library.

### Proposed solution
I propose refactoring the SPI ecosystem to allow for "Dependency Injection," where a library (like ESP8266AVRISP) accepts an SPI implementation in its constructor instead of being hard-coded to the global SPI object.

### My contribution
I have working solution with modified ESP8266AVRISP which use software SPI implementation I made. I can make PR if this propose is accepted