This enables more seamless interop between Torque and CSA:

Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.

Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.

To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.

As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.

Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}