Rename template upload/download to R503 specific

@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.

Start with the template upload/download example referenced in the issue and review how it identifies the R503-specific workflow. Rename the example to make that scope explicit and document what must change for non-R503 sensors; done means the example and its documentation no longer imply broad sensor compatibility.

Written by the indexing model from the issue text.