[ObjCDirectPreconditionThunk] Adding a flag to  with objc_direct symbols' prefix  (#170616)

## TL;DR

This is a stack of PRs implementing features to expose direct methods
ABI.
You can see the RFC, design, and discussion
[here](https://discourse.llvm.org/t/rfc-optimizing-code-size-of-objc-direct-by-exposing-function-symbols-and-moving-nil-checks-to-thunks/88866).

The stack of the following four PRs completes the whole feature.

https://github.com/llvm/llvm-project/pull/170616 **Flag
`-fobjc-direct-precondition-thunk` set up**
https://github.com/llvm/llvm-project/pull/170617 Code refactoring to
ease later reviews
https://github.com/llvm/llvm-project/pull/170618 Thunk generation
https://github.com/llvm/llvm-project/pull/170619 Optimizations, some
class objects can be known to be realized

## Implementation details

1. Add a flag. I used `-fobjc-direct-precondition-thunk` instead of
`-fobjc-direct-caller-thunks` as discussed in this PR.

2. Clean up and set up helper functions to implement later
a. `canMessageReceiverBeNull` / `canClassObjectBeUnrealized` these two
functions will be helpful later to determine which function (true
implementation or nil check thunk) we should dispatch a call to.
Formatting.
b. `getSymbolNameForMethod` has a new argument `includePrefixByte`,
which allows us to erase the prefixing `\01` when the flag is enabled
c. `usePreconditionThunk` is the single source of truth of what we
should do. It not only checks for the flag, but also whether the method
is qualified and we are in the right runtime. A method that
`usePreconditionThunk` is either `shouldHavePreconditionThunk` or
`shouldHavePreconditionInline`.

## Tests

Driver tests

---------

Signed-off-by: Peter Rong <PeterRong@meta.com>
Co-authored-by: Kyungwoo Lee <kyulee@meta.com>