Add rudimentary support for aliases in ov

[sarayourfriend]

Fixes

Fixes #4407 by @sarayourfriend
cc @dhruvkb and @AetherUnbound who will be the most immediately interested in this

Description

This approach is similar to the associative array approach, but worse because we cannot easily look up an alias by its name, and there's no non-trivial way for aliases to stack (i.e., refer to another alias). We could do that by not breaking, and continuing to replace the first entry in the args array each time an expansion is encountered, but that would make alias expansion and cross-reference dependent on the order in which they're defined.

This approach is also susceptible to coding errors, if the arrays are not an even number of entries, and it could be hard to debug that.

The Python alternative I've described in #4407 might be better in that regard. Implementing cross-referencing aliases would be trivial in Python (because we can use dicts) and there wouldn't be an ordering issue. It's also much harder to introduce a difficult to debug or non-obvious coding error with that approach.

I'll leave this as a draft and try the Python version to see which is better.

Testing Instructions

Try ov j, ov nuxt, and ov welcome. Define your own aliases. See if you understand the approach, does it feel easy to use, or is it too complicated?

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• I ran the DAG documentation generator (just catalog/generate-docs for catalog
  PRs) or the media properties generator (just catalog/generate-docs media-props
  for the catalog or just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[sarayourfriend]

Closing in favour of #4409 because it fixes some of the problems with this approach with no disadvantages, as far as I can see.