The is_shared bit bumps the number of reserved bits for Strings'
InstanceType from 6 to 7. This has the side effect of shuffling the
InstanceType enum values.

There are no users of this bit yet. This is steps 1-2 from the following
design doc [1], in preparation for sharing internalized and
in-place-internalizable strings.

[1] https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edit?usp=sharing

Bug: v8:12007
Change-Id: Idf11a6035305f0375b4f824ffd32a64f6b5b043b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266017
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77831}

As Nico pointed out in [1], it is a little strange that the pair of
annotations "@export @customCppClass" behaves similarly to the keyword
"extern": both indicate that the class is defined in a C++ file and
Torque generates only a base class template for it. In this change, I
explore a possible alternative which might be more consistent.

Removed annotations:
- @customCppClass, which required @export, instructed Torque to only
  generate a base class template instead of a full class.
- @customMap, which also required @export, instructed Torque to not emit
  code for setting up a unique Map instance for the class.

Added annotations:
- @generateUniqueMap, which requires extern, instructs Torque to emit
  code for setting up a unique Map instance for the class.
- @generateFactoryFunction, which requires extern, instructs Torque to
  emit a function for creating a class instance.

Subtracting two annotations and adding two others still leaves us with
way too many annotations, but the usage of "extern" becomes more
consistent and I think that the new opt-in annotations might be easier
to understand.

[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit

Bug: v8:7793
Change-Id: Ic9e147a095bc492d6645001b9275357386e8adcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266008Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77799}

Bug: v8:7793
TBR=hpayer@chromium.org

Change-Id: I88644c9476b74f57d3cf7a3056a9b70f1467b96d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489689
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71079}

This creates a .tq file in src/objects for each src/objects/*.h file
with Torque-defined classes and moves the object definitions and
corresponding helpers/macros there.
In addition, we create files convert.tq and cast.tq in src/builtins
to move the casts and conversions to.

Since Torque-generated .cc files end up as .o files in the same
directory, there cannot be two .tq files of the same name. Thus it
was necessary to rename src/builtins/arguments.tq and
src/builtins/string.tq to not clash with the new files in src/objects.

This is a mechanical change that only moves code.

Design doc: http://doc/1fh4OUMjQMnQdJm3aiAPXQUNdgbQugkRGdJzDh8hmyzk

Bug: v8:9861 v8:9810 v8:7793
Change-Id: I9c54cb50f32b9ae0fb41752199515133eb59ea5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910100Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64892}