chore: Use released code for publishing docs

[spalladino]

Removes the need to set INCLUDE_RELEASED_CODE when building docs, and just builds off the published images of sandbox and l1-contracts on dockerhub. This ensures that the API reference we are generating is actually from the latest release and not from whatever's on master (which is a bug we have today).

Note that we keep the INCLUDE_RELEASED_CODE logic in our docs build script just to try it out locally.

[spalladino]

Happy to change this for a branch check in each step of the job for consistency with deploy-and-release

[spalladino]

Note that this doesn't work as-is since include-code macros need access to both released code and latest code (as a fallback). This only gives access to latest code.

[spalladino]

Comments from Charlie on this PR from back in the day, so they don't just sit on my Slack:

We generate docs from l1-contracts as well? Sad face. (edit: ah, I see it's all around messaging stuff)
Docker ignore files can be next to their Dockerfile if named same as Dockerfile and postfixed .dockignore e.g. Dockerfile.prod.dockerignore
Why do we need a second Dockerfile and job/manifest entries? Do we not just make docs always build from released version? i.e. why not replace Dockerfile with Dockerfile.prod, what do we need Dockerfile for now?
buildDir can now be docs, which means in theory you can just name the dockerignore file .dockerignore.
No rebuild patterns required now, as we only need rebuild if docs changes, which is the default pattern if buildDir is docs and no rebuildPatterns are provided. (edit: Hmmmmm. This is true in the master case, but not in the tagged case, as the code may have changed, but the docs may not have. But it's also unnecessary to rebuild the docs if master code changed, as we don't use it in the docs. Perhaps the "correct" solution, is to use release-please to update the version tag on the FROM , this means its always clear what it's building off, and that the content-hash changes. Technically we could inject the version into any file covered by the rebuildPatterns, but that might be the most sensible thing.)
Shouldn't the job that depends on deploy-and-release deploy-docs, be the one that runs only for tags? and then we want to run the same job, but with no dependencies, on master. In fact for simplicity (otherwise we actually need to duplicate the same job), can we just have the same job run for both master and tags? Means that a master release has to wait for the whole pipeline but think that's ok for simplicity.
Also we're kind of using the term "release" for publishing stuff, and "deploy" for running infrastructure. So maybe name job release-docs.

And also an issue with this approach:

I spotted an issue with the solution I pushed: new docs that reference code from unreleased files need to be able to read from master. [...] We can handle this by building FROM the dockerhub released version and FROM the ecr cache, and copying them to different folders. It's doable, we just need to tweak this script a bit.

[spalladino]

Closing in favor of #4928