feat: ✨ from_easyocr detection added

[onuralpszr]

Description

EasyOCR detections added.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How has this change been tested, please provide a testcase or example of how you tested the change?

Google Collab: https://colab.research.google.com/drive/1GAFuDZwXrxWY0O6M8K8sGdmvNoc9R5i5?usp=sharing

Docs

• Docs updated? What were the changes:

Example Results

[LinasKo]

Hi @onuralpszr 👋

It turns out, this isn't the first instance of OCR we have in supervision. Florence 2 can return a region with OCR text.
(Ctrl+F for if task == "<OCR_WITH_REGION>":)

It uses the labels detected by the model and puts them into Detections.data["class_name"].

The question is whether we should change that, match it or ignore it.
I like the idea of distinguishing OCR results in a dedicated data field, but I'd to be careful about not breaking existing behaviour.

I suggest we change from_lmm, so if florence 2 was run with task of <OCR_WITH_REGION> (task is first key of result), both CLASS_NAME_DATA_FIELD and OCR_TEXT_DATA_FIELD are set to returned labels. Then, let's emit a small deprecation warning, advising that "class_name" will be removed and to use the OCR value (yes, even when they don't access the value - only when OCR results are set). We can then drop the "class_name" support in supervision 0.28.0.

[onuralpszr]

Based on conversation we made with @LinasKo, I decided to reduce complexity and doing a way without creating "deprecated" type I went for "class_name" that so it will match "CLASS_NAME_DATA_FIELD" and we don't need to change Florance-2 side as well.

[LinasKo]

Verified the docs, verified the results run in Colab (with color_lookup=sv.ColorLookup.INDEX added to each annotator). Going to check for regression in NCNN just in case.

[LinasKo]

Thanks @onuralpszr!

Merging this, after a few miniscule changes.