Make Scala interfaces more idiomatic

This is an umbrella for a couple of things I'd like to do for the Scala-specific interfaces in the `chart`, `table`, `easyform`, and `fileloader` packages.

1. ~~Change all `List` interfaces to use `Seq`. `Seq` is the generic type for an ordered collection, and will accept Scala `Array`, `Vector`, and `Range` (as well as `List`).~~
2. ~~Use `Any` instead of `AnyRef` where possible on input parameter types to avoid problems with using the Scala native types. Scala should handle auto-boxing of native numeric types.~~
3. Add companion object interfaces for construction. It's more common in Scala to overload the companion `apply` than to overload the constructor, and even without overloading, the advantage of not typing `new` all over the place in a notebook is clear. **Drawback:** It will be awkward if some classes don't have companion-based constructors, so new Scala code may be needed even if the Java classes involved have Scala-friendly types. Impact: some maintenance load for Scala compatibility.
4. ~~Compile-time type safety. This is tricky. The base classes are implemented in Java, which doesn't have any way to express constraints like "`Date` or `Number`", so they fall back to type `Object` and rely on run-time checking with exceptions. Scala can use type constraints to be more specific, and Scala programmers are used to having compile-time type checking be as strict as possible. Major concerns:~~
- Test code would have to written in Scala instead of Java
- The constraint handling code would need to change if the underlying constraints changed (e. g., support for `java.time.LocalDateTime` in `XYGraphics.setX`)
- This part of the code, while relatively isolated, would probably be opaque to anyone not fluent in Scala

So, I'm very much open to feedback on this. I think the first two items are low-cost/moderate-benefit. The others may be debatable, especially in terms of their impact on maintaining the Scala code when changes are made to the base libraries.