add support for the RFM95 board, fixes #13

[sillevl]

as suggested in #13 , this PR adds support for the RFM95 board.

Based on the pin configuration (most notably, when the antswitch == NC), the RFM95 configuration is detected. The state is preserved in an is_rfm95 boolean value, following the same principle and technique that is used for the detection of the murata.

When the RFM95 board is detected, the variant type is set to SX1276MB1LAS, which is compatible, and the set_sx1276_variant_type() method is skipped (as it is using the _ant_switch pin, that is not present in the RFM95 configuration, to determine configruation).

[kivaisan]

Detecting the product from pin configuration is not a very robust solution, so I would like to remove whole is_murata variable. By checking our currently supported radios and your radio, how about if we change the driver just so that if antswitch is defined as NC, it will skip the variant detection. Something like this:

void SX1276_LoRaRadio::set_sx1276_variant_type()
{
    if (_rf_ctrls.ant_switch != NC) {
        _ant_switch.input();
        wait_ms(1);
        if (_ant_switch == 1) {
            radio_variant = SX1276MB1LAS;
        } else {
            radio_variant = SX1276MB1MAS;
        }
        _ant_switch.output();
        wait_ms(1);
    } else {
        radio_variant = VariantNone;
    }
}

and force paboost register:

uint8_t SX1276_LoRaRadio::get_pa_conf_reg(uint32_t channel)
{
    if (radio_variant == VariantNone) {
        return RF_PACONFIG_PASELECT_PABOOST;
    } else if (channel > RF_MID_BAND_THRESH) {
        if (radio_variant == SX1276MB1LAS) {
            return RF_PACONFIG_PASELECT_PABOOST;
        } else {
            return RF_PACONFIG_PASELECT_RFO;
        }
    } else {
        return RF_PACONFIG_PASELECT_RFO;
    }
}

[hasnainvirk]

@sillevl Can you please checkout #14 and test with your solution ? Does it solve your problem ?

[kivaisan]

Closing this PR as PR #15 fixed the issue.