Refactor code to allow configuration

[julianstirling]

The first commit is really large as I was just trying to make a first pass through.

This PR will:

• [X] Stop the wholesale copying of python files into the build directory
• [x] Break code into smaller function
• [x] Use a setup.py to install the orchestration package and the nimble builder package
• [x] Move rack parameters into a parameter dataclass
• [x] Create an object to hold the nimble configuration for a specific build
• [X] Separate the process of generating shelves from assemblies, so cached shelves can be used in other builds (note cacheing doesn't work yet as the exsource files are overwritten rather than append/updated properly)
• [x] Create objects to hold component information, rather than use string based matching
• [x] Use orchestration runner for static build

Things that need to be done after this is merged:

• Use exsource (may require upstream improvements) to only regenerate shelves if they are needed
• Allow the NimbleConfiguration class to produce a unique hash that the server can use
• When generating a specific configuration, this should be generated to a new folder and zipped

[julianstirling]

Hi @jmwright, A bit of a chunky PR this one! It should be ready for review, and merging if you don't have any issues.

It is a little bit of a backwards step in that we no longer get the identified build zip. But there has been a lot of work to modularise and to make it so that generate and generate_static use the back end orchestration code. I think it best to merge before doing any more major changes and then I can work on getting builds for a specific configuration.

EDITED to say For some reason the if didn't work and this branch tried to deploy, but the protection rule stopped it. So the result is still good even if we get a "Some checks were not successful"

[jmwright]

@julianstirling Is there documentation on how to run this new code properly? I can create an environment, do pip install -e ., and then run both ./generate.py and ./generate_static.py. I'm not sure if I should be interacting with the orchestration script directly though.

[julianstirling]

Great question Jeremy. As of now the only way I have run it is running generate.py and generate_static.py this PR is more about getting it in the state where I feel that it is flexible enough that we could do other custom things. I don't actually have any examples or process for doing that yet.

Perhaps I'll update the README to explain this current state so it is clear? More complex interaction are still a bit of dev away.

[jmwright]

The README was the first place I looked after I checked out the code, so a little more information there probably wouldn't hurt.

Otherwise, I think this is ready to merge so that the next phase can start.

[julianstirling]

Thanks. Are you happy that if I fix the comment above and add something to the README, then I'll merge?

[jmwright]

Yes, +1 to merge.

[julianstirling]

Thanks. I have made minor tweaks to the README which point those wishing to run locally towards generate.md. This is then updated to explain how to install and run the project now.