Replace poetry with setuptools and nox

[avylove]

Move to a more standard install by using setuptools for package builds and Nox for isolating testing. This has the advantage of being more aligned with standards, moves closer to a publishable Python package, isolates different linting and checking activities, and consolidates dependencies.

LISA can now be installed as a regular Python package and installs a lisa command, but still needs to run in the repo root because the microsoft and example directories can't be packages as is.

Checks were also separated out so there is more parallelization and in GitHub Actions and it's easier to see what failed. 3.11 is added and currently fails, but marked as continue-on-error.

Next steps will include:

• Moving examples and microsoft so they can be installed with LISA
• Unpin dependencies
• Update internal repo to leverage changes
• Fix code for 3.11

[squirrelsc]

• Unpin dependencies

I thought it again, it may bring negative impact on stability on released LISA versions. Imaging someone not to upgrade LISA, the LISA should run succeed as before. If some package brings breaking change, it forces users to upgrade to latest LISA, and bring big interrupts.

[squirrelsc]

It's a big change, we need to rebase to main. So make every commit is meaningful.

[squirrelsc]

@LiliDeng the change looks good to me now. It's a big change on pipelines and dev env experience. Please have a try, and let me know, if there is any concern. If everything is ok, we can merge it in next Monday or Tuesday.

[avylove]

• Unpin dependencies

I thought it again, it may bring negative impact on stability on released LISA versions. Imaging someone not to upgrade LISA, the LISA should run succeed as before. If some package brings breaking change, it forces users to upgrade to latest LISA, and bring big interrupts.

We can look at it in a follow-up PR, but best practice is to pin dependencies as little as possible. Pinning dependencies moves the contract of trust from the individual projects to us. For well-maintained projects, we really don't need to pin anything. For less stable projects we can likely reduce the places in the version number we care about, =~1.2 vs ~=1.2.3. Regardless, we can discuss further in a follow-up PR.

[avylove]

@LiliDeng the change looks good to me now. It's a big change on pipelines and dev env experience. Please have a try, and let me know, if there is any concern. If everything is ok, we can merge it in next Monday or Tuesday.

Thanks @squirrelsc! Still working on a few minor items, but definitely ready for testing. @LiliDeng please let me know if you run into issues. Please make sure to pull the latest because I'll be cleaning up the commits once I get these last few items done.

[LiliDeng]

@squirrelsc @avylove ack