[#26284] Replace "it's" with "it is" in docs

docs/src/main/asciidoc/hibernate-orm-panache.adoc

@@ -208,7 +208,7 @@ person.persist();
 // note that once persisted, you don't need to explicitly save your entity: all
 // modifications are automatically persisted on transaction commit.
 
-// check if it's persistent
+// check if it is persistent
 if(person.isPersistent()){
     // delete it
     person.delete();
@@ -395,7 +395,7 @@ personRepository.persist(person);
 // note that once persisted, you don't need to explicitly save your entity: all
 // modifications are automatically persisted on transaction commit.
 
-// check if it's persistent
+// check if it is persistent
 if(personRepository.isPersistent(person)){
     // delete it
     personRepository.delete(person);
@@ -817,7 +817,7 @@ public class RaceWeight {
 // Only the race and the average weight will be loaded
 PanacheQuery<RaceWeight> query = Person.find("select d.race, AVG(d.weight) from Dog d group by d.race).project(RaceWeight.class);
 ----
-<1> Hibernate ORM will use this constructor. When the query has a select clause, it's possible to have multiple constructors.
+<1> Hibernate ORM will use this constructor. When the query has a select clause, it is possible to have multiple constructors.
 
 [WARNING]
 ====
@@ -846,8 +846,8 @@ Make sure to wrap methods modifying your database (e.g. `entity.persist()`) with
 CDI bean method `@Transactional` will do that for you and make that method a transaction boundary. We recommend doing
 so at your application entry point boundaries like your REST endpoint controllers.
 
-JPA batches changes you make to your entities and sends changes (it's called flush) at the end of the transaction or before a query.
-This is usually a good thing as it's more efficient.
+JPA batches changes you make to your entities and sends changes (it is called flush) at the end of the transaction or before a query.
+This is usually a good thing as it is more efficient.
 But if you want to check optimistic locking failures, do object validation right away or generally want to get immediate feedback, you can force the flush operation by calling `entity.flush()` or even use `entity.persistAndFlush()` to make it a single method call. This will allow you to catch any `PersistenceException` that could occur when JPA send those changes to the database.
 Remember, this is less efficient so don't abuse it.
 And your transaction still has to be committed.
@@ -1189,7 +1189,7 @@ public class PanacheFunctionalityTest {
 When it comes to writing Hibernate ORM entities, there are a number of annoying things that users have grown used to
 reluctantly deal with, such as:
 
-- Duplicating ID logic: most entities need an ID, most people don't care how it's set, because it's not really
+- Duplicating ID logic: most entities need an ID, most people don't care how it is set, because it is not really
 relevant to your model.
 - Traditional EE patterns advise to split entity definition (the model) from the operations you can do on them
 (DAOs, Repositories), but really that requires a split between the state and its operations even though

docs/src/main/asciidoc/hibernate-reactive-panache.adoc

@@ -206,7 +206,7 @@ Uni<Void> persistOperation = person.persist();
 // note that once persisted, you don't need to explicitly save your entity: all
 // modifications are automatically persisted on transaction commit.
 
-// check if it's persistent
+// check if it is persistent
 if(person.isPersistent()){
     // delete it
     Uni<Void> deleteOperation = person.delete();
@@ -372,7 +372,7 @@ Uni<Void> persistOperation = personRepository.persist(person);
 // note that once persisted, you don't need to explicitly save your entity: all
 // modifications are automatically persisted on transaction commit.
 
-// check if it's persistent
+// check if it is persistent
 if(personRepository.isPersistent(person)){
     // delete it
     Uni<Void> deleteOperation = personRepository.delete(person);
@@ -678,7 +678,7 @@ PanacheQuery<DogDto> query = Dog.findAll().project(DogDto.class);
 It's also possible to specify a HQL query with a select clause. In this case, the projection class must have a constructor
 matching the values returned by the select clause:
 
-source,java]
+[source,java]
 ----
 import io.quarkus.runtime.annotations.RegisterForReflection;
 
@@ -700,16 +700,17 @@ public class RaceWeight {
 // Only the race and the average weight will be loaded
 PanacheQuery<RaceWeight> query = Person.find("select d.race, AVG(d.weight) from Dog d group by d.race).project(RaceWeight.class);
 ----
-<1> Hibernate Reactive will use this constructor. When the query has a select clause, it's possible to have multiple constructors.
+<1> Hibernate Reactive will use this constructor. When the query has a select clause, it is possible to have multiple constructors.
 
 [WARNING]
 ====
 It's not possible to have a HQL `select new` query and `.project(Class)` at the same time - you need to pick one approach.
 
 For example, this will fail:
-```
+[source,java]
+----
 PanacheQuery<RaceWeight> query = Person.find("select new MyView(d.race, AVG(d.weight)) from Dog d group by d.race).project(AnotherView.class);
-```
+----
 ====
 
 == Multiple Persistence Units
@@ -727,8 +728,8 @@ NOTE: You cannot use `@Transactional` with Hibernate Reactive for your transacti
 and your annotated method must return a `Uni` to be non-blocking. Otherwise, it needs be called from a non-`VertxThread` thread
 and will become blocking.
 
-JPA batches changes you make to your entities and sends changes (it's called flush) at the end of the transaction or before a query.
-This is usually a good thing as it's more efficient.
+JPA batches changes you make to your entities and sends changes (it is called flush) at the end of the transaction or before a query.
+This is usually a good thing as it is more efficient.
 But if you want to check optimistic locking failures, do object validation right away or generally want to get immediate feedback, you can force the flush operation by calling `entity.flush()` or even use `entity.persistAndFlush()` to make it a single method call. This will allow you to catch any `PersistenceException` that could occur when JPA send those changes to the database.
 Remember, this is less efficient so don't abuse it.
 And your transaction still has to be committed.
@@ -1068,7 +1069,7 @@ public class PanacheFunctionalityTest {
 When it comes to writing Hibernate Reactive entities, there are a number of annoying things that users have grown used to
 reluctantly deal with, such as:
 
-- Duplicating ID logic: most entities need an ID, most people don't care how it's set, because it's not really
+- Duplicating ID logic: most entities need an ID, most people don't care how it is set, because it is not really
 relevant to your model.
 - Dumb getters and setters: since Java lacks support for properties in the language, we have to create fields,
 then generate getters and setters for those fields, even if they don't actually do anything more than read/write