Rename public binaries to Octez

Context

Issue: #1737

The purpose of this MR is to rename public executables and other scripts that behave like executables (such as docker entrypoints). Furthermore, we want to support a deprecation period which allows others to continue to use the old names as long as a warning is emitted to let them know to migrate to the new names. As you may know, the definition of Tezos has been split into two parts: 1) the protocol itself, 2) everything else. The protocol will continue to remain "Tezos", while everything else (nearly everything in this repo) which is considered as an "implementation" of Tezos, is to be renamed to Octez.

A rename of this magnitude is challenging to execute because of several reasons.

• The surface area is large. This repo contains many libraries, executables, tests, scripts, docs, packages, and other resources which have been labeled "tezos".
  • I have tried by best to rename as little as possible in this first pass. Initially the goal was to rename only the executable names and the packages, but the worked spiraled outwards as references to these tools and their outputs were discovered in the docs and the tests.
• There are many concurrent developers adding, deleting, and reorganizing the codebase at all times. So it is important to remain current with regards to rebases.
  • On this note, it quickly became clear to me that manually rebasing would be far too cumbersome and would not scale well. So, I divided the commits into 2 parts: 1) commits which must be done manually, 2) commits which can be automated by a script. Once the script was written, it became trivial to rebase the branch.

Manually testing the MR

Probably the best way to test the MR is to try to find public binaries and binary-likes that are not renamed or do not emit a warning message when called with the tezos-* prefix. Note, the renaming of libraries is currently excluded from this MR, and any suggestions to rename libraries will likely be out of scope for this MR.

Other than that, I have based my success criteria upon the green lights in the CI pipeline.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR