Fix `Schemaview.import_closure` order

Fix: https://github.com/linkml/linkml/issues/1839 Also:

Fix: https://github.com/linkml/linkml/issues/1825
Related to: https://github.com/linkml/linkml/issues/584

Previously on this issue....

the schemaview was doing an ordering that was almost perfectly backwards, not allowing one to redefine classes that had already been declared in an imported schema.

Fix Ordering

Two substantive changes:

1) use a deque and `appendleft`

(probably a perf wash vs. reverse but wanted to keep operation grouped): the pop and append operations make a FILO queue, and so we want earlier visited items (eg. the imported module) to be at the end of the imports closure.

For intuition, in the sample import tree, the first layer of imports is

imports:
- linkml:types
- s1
- s2
- s3

so the todo list will have ['linkml:types', 's1', 's2', 's3']

on the next iteration we

pop (right) s3 from todo,
add its imports to todo: ['linkml:types', 's1', 's2', 's3_1', 's3_2']
leftappend s3 to closure: ['s3', 'main']`

and so on.

2) only check for uniqueness to avoid cycles

remove uniqueness checking in closure appends, and add to visited at the end of the loop rather than the start.

This is mostly to fix the case where a schema (like linkml:types) is imported multiple times in the tree. Currently, it would be inserted in the last place it appears (since the import resolution order effectively works backwards). In this change we add it everywhere that it is actually imported, but only follow its imports the first time it appears. This is an imperfect fix that comes from needing to flatten a graph that can be completed once the schemaview class behaved recursively.

We then filter duplicates, keeping the first appearance using a dictionary comprehension.

Also Changed

`traverse` param:

I noticed that the traverse parameter behaved identically to the imports parameter, but i could only see the imports parameter being used. I switched that to being default None so it would only to a deprecation warning if you attempted to use it. I don't know how y'all handle deprecations so lmk how to handle that.

issue 998 tests

I'm not sure why I affected this here, but this test was incorrectly specifying that there was only one slot that used 'EmploymentStatusEnum' (which actually doesn't exist in the schema, it's named 'EmployedStatusEnum', so maybe schemaview needs some tests for whether a thing exists when referring to it?), but there are actually two slots that do:

past_employer, a slot: https://github.com/linkml/linkml-runtime/blob/c9adcaeb405804efcf19bd4fcfc950a8ddb173e1/tests/test_issues/test_linkml_issue_998.py#L44
employed, an attribute: https://github.com/linkml/linkml-runtime/blob/c9adcaeb405804efcf19bd4fcfc950a8ddb173e1/tests/test_issues/test_linkml_issue_998.py#L21

And since there are actually two employed attributes, there should really be 3 slots identified there, but since they are just indexed by slot name they are collapsed down to 2.

idk i didn't want to change too much there, but that's sort of a warning sign that there might be something wrong elsewhere in schemaview, but i changed it so the tests correctly pass, not sure why they were passing before.

linkml / linkml-runtime