Init thumbnail rework.

[markpbaggett]

What Does This Do?

Skips Cantaloupe for audio / video thumbnails and fixes Issue-141.
Manifest generation was slow for items with many audio/video files (e.g. taboca_201002_03, 251 canvases) because every thumbnail (including AV thumbnails) were routed through Cantaloupe's IIIF image service via create_thumbnail_from_iiif. For AV items this is unnecessary round-trip overhead per file and a needless dependency on the image server for content that isn't an image derivative.

This change runs things through addThumbnails based on mediatype:

• movies, audio, etree: build the thumbnail directly from a static archive.org/download/... URL instead of calling Cantaloupe. Movies get no explicit width/height; audio/etree get width/height from file metadata if present, otherwise a 192×108 default.
• Everything else (images, texts, etc.): unchanged. It still goes through Cantaloupe, but now falls back to the same static-URL approach

[glenrobson]

Audio we think we can hard code dimensions

Video we are thinking of removing height and width and testing with viewers as this is a 'should' in the spec.

[glenrobson]

Discussing this in the 5th march call and wondered if the video thumbnail would be the same size as the video. We must have the height and width for the video as its required for the canvas.

Audio should be static sizes.