Stop passing classes and default_classes to export and evaluation methods

[brimoor]

Resolves #1722.

This is scratching a pretty deep itch, and it feels oh so good 🥇

The fact that certain API methods would silently search for class lists on Dataset.classes and Dataset.default_classes often caused unexpected behavior for users that had first used something like filter_labels() to select a subset of classes to work with (see #1722 for details).

Lesson learned: don't be fancy, let the user store class lists, but prefer relying on the user to explicitly request certain behavior:

# bad: silently access dataset.default_classes to locate classes
dataset.some_method(...)

# good: let user explicitly tell us what to do
dataset.some_method(..., classes=dataset.default_classes)

NOTE: there's still one important place that will silently infer class lists: the annotation API. My reasoning there is, even if the user first did something like filter_labels() to extract a view of interest to annotate, they are very likely to want all possible classes from their schema available for use when annotating.

^removed default classes/mask targets from the annotation API too

[ehofesmann]

This LGTM, but I would argue that this could be extended even to the annotation API. If you filter out some classes from the view, it still uses the underlying dataset (and the view) to get the entire list of classes so you don't need to be concerned about missing labels:

fiftyone/fiftyone/utils/annotations.py

Lines 780 to 783 in aa076d0

	return sorted(
	set(samples._dataset.distinct(label_path))
	| set(samples.distinct(label_path))
	)

Also, I have serious doubts that many users actually use or even know about the existence of dataset.classes and dataset.default_classes, so in the case that they do want to specify classes that don't exist yet, they would probably be providing them manually anyway. Though for the same reason, there's also not much of a reason to change the way the annotation API works currently. It would only trip people up if they have default classes defined for one field and go to annotate another field with different classes, which I suppose could happen but I've never seen it yet.

[brimoor]

This LGTM, but I would argue that this could be extended even to the annotation API. If you filter out some classes from the view, it still uses the underlying dataset (and the view) to get the entire list of classes so you don't need to be concerned about missing labels

@ehofesmann you're a wise man 🧙‍♂️
I removed default classes/mask targets from the annotation API too 👍