docs: hacking: emphasize some sections

Namely:
* holding up the first-time patch submissions for moderation,
  which might cause first-time submitters to question the process
* not CC-ing individual developers
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

docs/hacking.html.in

@@ -72,8 +72,8 @@
 </pre>
         <p>As a rule, patches should be sent to the mailing list only: all
         developers are subscribed to libvir-list and read it regularly, so
-        please don't CC individual developers unless they've explicitly
-        asked you to.</p>
+        <strong>please don't CC individual developers</strong> unless
+        they've explicitly asked you to.</p>
         <p>Avoid using mail clients for sending patches, as most of them
         will mangle the messages in some way, making them unusable for our
         purposes.  Gmail and other Web-based mail clients are particularly
@@ -81,9 +81,11 @@
         <p>If everything went well, your patch should show up on the
         <a href="https://www.redhat.com/archives/libvir-list/">libvir-list
         archives</a> in a matter of minutes; if you still can't find it on
-        there after an hour or so, you should double-check your setup.  Note
-        that your very first post to the mailing list will be subject to
-        moderation, and it's not uncommon for that to take around a day.</p>
+        there after an hour or so, you should double-check your setup.
+        <strong>Note that, if you are not already a subscriber, your very
+        first post to the mailing list will be
+        subject to moderation</strong>, and it's not uncommon for that to
+        take around a day.</p>
         <p>Please follow this as close as you can, especially the rebase and
         <code>git send-email</code> part, as it makes life easier for other
         developers to review your patch set.</p>