refactor to latest Legolas version + onda.signal v2

[jrevels]

• upgrades to Legolas v0.5 (xref refactor package to remove sharp edges for schema authors/users (particularly @row / Row) and improve API Legolas.jl#54) (and will close write_annotations/write_signals errors when given empty tables #82, since those functions are being deprecated in the switch to Legolas v0.5)
• resolves enable more granular notion of sensor for onda.signal #119
• resolves Onda is not currently compatible with TimeSpans 0.3 #123 (relatedly, this PR requires a merge/tag of improve consistency of time <-> index conversion TimeSpans.jl#51)
• obviates avoid decoding sample data as Ints #99. I've been wanting to simplify the field types for sample_rate, sample_offset_in_unit, and sample_resolution_in_unit for a long time. I figured that it's actually easier on data producers/consumers to do this as part of one breaking change than to do this as part of multiple breaking changes. Luckily I did a mini-audit of a bunch of larger Beacon datasets internally and they all complied already, so I think it'll be uncommon for this to even affect anybody.

Tests pass locally, but will require beacon-biosignals/TimeSpans.jl#51 to pass in CI.

Otherwise, I still have some documentation/deprecation work to do here; will be in draft mode until that's done, but would very much welcome review. It'll be important Beacon-timeline-wise to get this merged/tagged by EOW.

Note that changes that were breakages in Legolas will be hard to deprecate here, but I'll try to provide decent upgrade paths where possible. However, similarly to beacon-biosignals/Legolas.jl#54:

Note that Beaconeers aren't expected to upgrade to v0.15 internally without dedicated support from the relevant team members (if you have a question about this, feel free to ping me in Beacon's internal Slack). So feel free to upgrade "early" if you want to for your use case, but keep in mind that it's not a requirement.

[ericphanson]

lgtm!

[ericphanson]

I should understand this but in the likely case I don't, does this mean:

1. If a table has been serialized with some other AbstractString for e.g. sample_unit, it can be deserialized OK?
2. do we need sample_unit::String = string(sample_unit) in the @version invocation? or String(sample_unit)? If not, why not?

[jrevels]

If a table has been serialized with some other AbstractString for e.g. sample_unit, it can be deserialized OK?

yup

do we need sample_unit::String = string(sample_unit) in the @version invocation? or String(sample_unit)? If not, why not?

Declaring a required field as f::T is Legolas shorthand for f::T = f, which is Julia shorthand for f::T = convert(T, f). This matches the previous behavior on main which had the convert call explicitly (and unnecessarily)

We could add = string(sample_unit) to auto-stringify non-string-convertable inputs, but in this case, I'd rather callers just do that themselves if that's what they want