Specify interaction between component build systems

Nobody has claimed this yet.

We currently have multiple build systems for the different components of OpenTitan, but have not finally agreed on a way how those build systems interact. This is especially critical now that we're seeing more and more chip-level work where build artifacts from different components need to be plugged together.

I have created a document outlining the status quo at https://docs.google.com/document/d/1UxT0jkrGfwvOf6KYoEnrTgWdft-aWjNCoKf06_7C05Y/edit#.

While software, FPGA and Verilator chip-level simulation builds as well as end-to-end system tests are written (and used in CI) to be called individually and build artifacts to be stored in $BIN_DIR, dvsim assumes (and expands more towards) being a "all in one" build system which operates in its own build directory structure and also, for example, triggers software builds when needed for a chip-level DV run. This leads to two ways of building components existing next to each other.

We need to clarify:
1. How do we want the cross-component builds to happen?
1. Are we happy with the current lack of a high-level build system, which instead relies on the developer (or CI logic) to orchestrate component builds? If not, how could a minimal solution to that problem look?
1. Do we want dvsim to be the "high-level build system" that everybody uses? If so, what extensions would be necessary to enable parallelized and distributed multi-stage builds, as we do them in CI?

I'm proposing for everyone to have a look at the linked document and think about the problem. Please comment if you have input, and I'll then try to follow up as necessary (probably in one of the meetings, and then with a final proposal/doc change).

Read the linked design document and compare its status quo with the component builds that store artifacts in $BIN_DIR and the dvsim build-directory workflow. Review how software, FPGA, Verilator chip-level simulation, and end-to-end tests are invoked in CI. Done means a decided cross-component build model and a final proposal or documentation change covering orchestration and any required dvsim extensions.

Written by the indexing model from the issue text.