Rename template upload/download to R503 specific

[admiralmaggie]

@jerryneedell I finally got a chance to test the optical sensors. I got two different models:

https://www.adafruit.com/product/4690
and
https://www.adafruit.com/product/751

As you suspected, the LED method is causing issues with these two units. The good thing is the template upload/download does work but there is a wierd extra packet being sent by these two modules when asked to compare two template (instruction 03x):

*** DEBUG ==> _send_packet data: ['ef', '01', 'ff', 'ff', 'ff', 'ff', '01', '00', '03', '03', '00', '07']   
*** DEBUG ==> _get_packet received data: ['ef', '01', 'ff', 'ff', 'ff', 'ff', '07', '00', '03', '01', '00', '0b']  <<=== Failure packet
*** DEBUG ==> _get_packet reply: ['01']  
*** DEBUG ==> _get_packet received data: ['ef', '01', 'ff', 'ff', 'ff', 'ff', '07', '00', '05', '00', '00', 'ff', '01', '0b']  <<=== Followed by proper expected packet
*** DEBUG ==> _get_packet reply: ['00', '00', 'ff']  
*** DEBUG ==> compare_templates confidence: (255,)  
Fingerprint match template in file.   

It sends error when receiving package (01x) followed by a proper/expected packet. It does not appear to affect the functionality.

I guess The easiest thing to do is to create PR and rename the template upload/down example to R503 specific. We can just document what needs to be done to make the example work with non R503 sensors.

[jerryneedell]

It appears that the "soft_reset" command is also only available for the R503.
Not sure how best to handle the differences.

[admiralmaggie]

@jerryneedell I guess we could make the sensor type a parameter in the constructor method (called type=) and derive what is supported from there. Something like that.