Lazy State: Maybe use `@` instead of `$`

The Lazy State operator uses $ to read from state. For example:

get($.url)

Some benefits of using $ are:

• It is valid JS syntax, so get($.url) will run in plain JS and not freak out any linters/validators
• It is like JSON path, which uses $ for root. And JSON path is sort of the model it's based on
• It's also a bit like a jquery selector, for people old enough to remember jquery
• $ is often used as a special variable in JS, devs are kind of used to it

Problems with $ are:

• Yes, the code will compile and even run - but you'll get type errors in native JS. Job code isn't really executable until it's been put through the compiler.
• It's really really ugly in template literals because of the double dollar, ie:

get(`resource/${$.data.id}`)

Benefits of using @ are:

• @ is a symbol related do addressing generally, which fits nicely with @path.to.state
• @ is is not valid JS, helping openfn code stand out as distinct from JS.
• It's stronger branding and more distinct than dollar
• It plays well with the compiler
• Works great in template literals
• It's quite easy to explain
• We can keep $ as an alias for the short-medium term

But the problems with @ are:

• Source editors like VSCode and Monaco (and so Lightning) won't recognise @ and will complain. Yes we can add support in Lightning an extend the syntax, but those using third party tools for local dev will have a worse experience
• We've already launched $ and are using it in production code. I don't want to re-write everything and retrain now! On the other hand, it IS still new and flagged as experimental, so maybe there's still time for a dramatic change

I think the bottom line with @ is that it's better branding and basically good for us, but it moves the openfn DSL a step closer to being a distinct formal language, meaning we need to support .ojs files and create OpenFn JavasScript language definitions.

To be honest actually $ is no different - it SHOULD be treated as a different language statement, with linting rules and syntax highlighting associated with it. And $ won't run without compilation anyway.

So maybe introducing @ just forces us to be more honest about our coding language.

However, I don't want to do all that stuff if we're going to throw it away next year in favour of a v3 langauge syntax, as is being discussed in the dark corridors of power here...

No files, tests, or entry points are named. First review the existing Lazy State implementation and the discussion of the possible v3 language syntax; done would require a decided operator direction and an agreed scope for compatibility, tooling, and language support.